Security gets specified in one of two ways. Either it is four lines in a brief saying the system will be secure and follow best practice, or it is a document from an information security team written for a system that does not exist yet and half of which does not apply.
Neither produces a secure system, and neither gives a supplier anything to price. What works is smaller than the second and far more specific than the first.
Why the timing matters more than the content
Most security controls can be added at any point. A handful cannot, and the difference is whether the control is a feature or an assumption baked into the data model.
The authorisation model is the whole argument for doing any of this early. A system built on “managers can see the team’s records” and one built on “a user can see a record if they are named on it, or their delegate is, or it belongs to a case they are assigned to” are different systems, not the same system with a different setting. Discovering the second requirement after launch means revisiting every query that reads data.
The six things to write down
Who sees what
Not a list of roles. The rule that decides whether a given person can see a given record, including the awkward cases: delegated access, temporary cover, contractors, support staff acting on a customer’s behalf, and what an administrator can see.
Write one sentence per role describing what it can read and change, then find the case that sentence gets wrong. There always is one, and it is usually the reason the model has to be record-level rather than role-level.
Where the data lives
Which region data is stored in, which region it is processed in, and every third party that touches it. Those are three different questions and contracts usually only answer the first.
Ask for the sub-processor list as a deliverable, kept current. If you are building on managed AI services this gets sharper, and we cover it in building an AI feature on your own data.
How long you keep it
Per record type, not one blanket policy. Orders, support conversations, audit logs, uploaded documents and analytics events all have different answers, and some are set by law rather than preference.
Specify deletion as a feature with acceptance criteria. “Delete my account” that leaves the record in three caches, a search index, a data warehouse and last night’s backup is not deletion, and that is the default outcome unless someone wrote it down.
What gets logged
Which events produce an audit record, what each record contains, how long it is kept, whether it can be altered, and who is allowed to read it. Audit logs frequently contain the most sensitive data in the system and are the least access-controlled part of it.
Name the questions the log must answer rather than listing events. “Who viewed this customer’s record last month” is a requirement. “Log all access” is not.
Which rules apply
Card data, health data, children’s data, financial records, sector rules, and the state privacy laws that reach you. Each brings specific, costable obligations, and naming them in the brief is far cheaper than discovering them in an audit.
Put the regimes in the brief by name, and ask the supplier which requirements in each one affect the architecture rather than the process.
How you patch
Who watches for vulnerabilities in your dependencies, how quickly a critical fix ships, and how you know what is in the system at all. A dependency inventory is the prerequisite: you cannot patch what you have not catalogued.
Agree a time-to-patch commitment for critical severity before signing, and ask who is responsible for it after the engagement ends. This connects directly to what maintenance actually costs.
The US compliance picture has changed, quietly
Two developments are worth putting in front of anyone still treating compliance as a European problem.
And for anyone handling card data: since 31 March 2025, all 51 previously future-dated requirements in PCI DSS v4.x are mandatory and validated in every assessment, with no grace period. Several of those are architectural rather than procedural:
- Requirement 8.3.6 raises the minimum password length to 12 characters, up from 8.
- Requirement 8.4.2 requires multi-factor authentication for all non-console access to the cardholder data environment, from any location. Not just remote access.
- Requirement 6.4.3 requires every script on a payment page to be documented, tracked and authorised. In practice this means knowing what your tag manager is loading.
- Full disk encryption is no longer acceptable on its own as a method of protecting stored card data.
Requirement 6.4.3 catches people who thought they had no PCI scope. A store that outsources payment to a hosted provider still serves the page the payment form sits on, and every marketing tag on that page is now in scope. If nobody can produce a list of scripts on your checkout page and who authorised each one, that is a finding waiting to happen.
Use a framework instead of writing a checklist
NIST’s Secure Software Development Framework, published as SP 800-218, exists precisely so that buyers and suppliers can talk about this without each inventing their own vocabulary. It came out of US Executive Order 14028 and organises practices into four groups: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities.
It is not a regulation with an enforcement date, and it is not a certification. It is a shared list of the things a competent software team does, which makes it exactly the right thing to reference in a brief. Asking a supplier how they address the four practice groups produces a far more useful conversation than asking whether they follow best practice. There is also a companion profile, SP 800-218A, covering generative AI and dual-use foundation models, which is worth naming if that is what you are building.
What to put in the brief
That is two pages. It is enough for a supplier to price accurately, and it front-loads exactly the decisions that are expensive to revisit. The same logic runs through writing a brief that gets accurate quotes: specify the constraints, not the solution.
Answers that should worry you
- “We follow industry best practice.” Ask which practices, and how they would show you. A supplier who works this way can name a framework.
- “That’s a hosting concern.” Some of it is. Authorisation, audit logging and deletion are not.
- “We’ll add that later.” Fine for the top of the retrofit chart, expensive for the bottom two.
- “The framework handles it.” Frameworks provide mechanisms. Your access rules are yours.
- No dependency inventory. If they cannot list what is in the system, they cannot patch it and neither can you.
- Compliance treated as documentation. Some requirements are paperwork. Several of the PCI ones above are code.
None of this requires you to become a security specialist. It requires you to ask six questions before the architecture is fixed rather than after, which is a scheduling decision more than a technical one.
Related: what happens in a discovery phase is where these questions belong, choosing a development partner covers judging the answers, and what you should own when a build ends covers the credentials and documentation side.
We work these six questions into discovery rather than treating security as a review at the end, because by the end the expensive ones are already decided. If you have a build starting and want the security brief written properly, tell us what the system will hold.
Common questions
What security requirements should be specified before development starts?
Six: the rule deciding who can see which record including delegated and support access, where data is stored and processed and which third parties touch it, retention and deletion per record type, which events produce audit records and who can read them, which compliance regimes apply by name, and who watches for vulnerabilities with what time-to-patch commitment. The first is the one that must be settled early, because changing the authorisation model later rewrites the data access layer.
What changed in PCI DSS 4.0.1?
Version 4.0.1 clarified v4.0 rather than adding requirements, but as of 31 March 2025 all 51 previously future-dated requirements became mandatory in every assessment with no grace period. The architectural ones include a 12-character minimum password length (8.3.6), multi-factor authentication for all non-console access to the cardholder data environment from any location (8.4.2), documenting and authorising every script on a payment page (6.4.3), and the removal of full disk encryption as a sufficient method of protecting stored card data on its own.
Do US state privacy laws apply to my software?
Increasingly, yes. Twenty states have comprehensive consumer privacy laws in effect in 2026, with Indiana, Kentucky and Rhode Island joining on 1 January 2026, Louisiana and Oklahoma on 1 January 2027, Alabama on 1 May 2027 and Vermont on 1 January 2028. Applicability depends on thresholds that vary by state, so the practical question is which of your customers live where, and that belongs in the brief rather than in a later legal review.
What is the NIST Secure Software Development Framework?
NIST SP 800-218, a set of high-level secure development practices produced in response to US Executive Order 14028, organised into four groups: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. It is not a regulation or a certification, which is what makes it useful in a brief: it gives buyer and supplier the same vocabulary. A companion profile, SP 800-218A, covers generative AI and dual-use foundation models.
Sources
- PCI Security Standards Council: PCI DSS v4.0.1 replaced v4.0 effective 31 December 2024 and provides clarification without changing v4.0 requirements. All 51 previously future-dated requirements became mandatory and are validated in all assessments from 31 March 2025, with no grace period. Requirement 8.3.6 sets a 12-character minimum password length. 8.4.2 requires multi-factor authentication for all non-console access to the cardholder data environment from any location. 6.4.3 requires payment page scripts to be documented, tracked and authorised. Full disk encryption alone is no longer an acceptable method of protecting stored account data.
- NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, developed in response to Executive Order 14028. Four practice groups: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV). NIST SP 800-218A is the community profile for generative AI and dual-use foundation models.
- US state comprehensive consumer privacy laws: twenty in effect during 2026, with California, Virginia, Colorado, Connecticut and Utah as the first wave and Indiana, Kentucky and Rhode Island effective 1 January 2026. Louisiana and Oklahoma take effect 1 January 2027, Alabama 1 May 2027 and Vermont 1 January 2028. Florida’s Digital Bill of Rights is narrower in scope than the others and applies only to very large technology companies. Counts are of laws in effect rather than enacted, and applicability thresholds differ by state.
- This article is general commercial guidance, not legal advice. Whether a given regime applies to you depends on facts a lawyer should assess.
Written September 2026.
