Write acceptance criteria that can be checked on delivery day: lockfiles committed, a dependency inventory attached, no unresolved high severity advisories without a recorded decision, secrets stored outside the repository, named access accounts, and a handover pack. Avoid promises like "secure" that nobody can test.
This is a planning aid, not legal advice. Have counsel review contract language.
Why vague language hurts both sides
"The site will be secure" cannot be accepted or rejected. When something goes wrong, the argument is about what was meant. Criteria that name a check and an artifact leave less room for dispute, and they give the client something concrete to pay for.
Examples to adapt
| Area | Criterion | How it is checked |
|---|---|---|
| Dependencies | Lockfile committed and CI installs from it | Look at CI config and repo |
| Inventory | Dependency inventory or SBOM provided, dated within 7 days of delivery | File in the handover pack |
| Known advisories | No unresolved high or critical advisories in production dependencies, or a written decision for each | Scan report plus decision log |
| Secrets | No credentials in the repository or history; secrets in the CI secret store | Search results and CI settings |
| Access | Each person has a named account with MFA, no shared logins | Access list |
| Pipelines | Production deploy requires an approval step | Workflow and environment settings |
| Runtime | Language and framework versions are supported at delivery | Version list with support dates |
| Licenses | License inventory provided | File in the pack |
| Handover | Build steps tested by someone outside the team | Written confirmation |
Adjust thresholds to the project. A brochure site and a payments portal need different bars.
Define the clock
Many findings appear after delivery. State what the agency owns and for how long. Options include a warranty window for issues present at delivery, a maintenance retainer for ongoing updates, or neither, with the client taking over at handover. Write which one applies. Our post on who owns updates after launch lays out the models.
Avoid overpromising
- "Free of vulnerabilities" cannot be proven. Use "no known unresolved advisories at the scan date."
- "Compliant with" a framework or regulation needs a named standard and a scope. Many clients mean "aligned with".
- "Penetration tested" means little without scope, dates and a report.
Make it testable by the client
If the client cannot verify a criterion, include how. Attach commands or screenshots in the handover pack. A criterion the client can re-run themselves builds trust.
Steps to put this in practice
- Start from the table and delete what does not apply.
- Add numbers: days, severities, counts.
- Name the artifact for each criterion.
- Agree who signs off.
- Review with counsel.
Quick check
Should security be a separate line item?
Often helpful. It makes the work visible and avoids it being cut first under pressure. Your commercial team decides how to price it.
What if the client refuses the criteria?
Record the refusal and the risk in writing, and keep the lighter criteria you can still deliver.
Sources
Last reviewed: 19 October 2026.
