TL;DR: The short version, in the order it will matter.
- Verifiable security is the only kind you own. If your vendor can’t provide evidence, it’s hard to defend to an auditor, a customer, or a regulator.
- Three separate layers are in play, and they are not interchangeable: how the code is verified, how the team works, and what law or contract asks of the finished product.
- Under the Cyber Resilience Act, the manufacturer is whoever markets the product under their own name if it is placed on the EU market. Hiring a vendor to write the code does not change who the manufacturer is.
- Require in writing: architectural requirements settled before design, acceptance criteria that can be tested, and a handover package named item by item.
Secure custom software development is sold with adjectives and settled with artifacts. A vendor can run threat models, pin every dependency, and review every pull request, and none of that exists for you unless it arrives as something you can read, test, or put in front of an auditor.
When another company writes the code, the buyer needs to know:
- Which security requirements are testable
- Who verifies them
- What evidence will be delivered
Security in software development, when the code is written by someone else, is verifiable to exactly the degree your contract made it verifiable. The phases of a secure development lifecycle are documented elsewhere; what follows is what to require, accept, and receive.
What “secure” means when someone else builds your software
“The vendor follows OWASP” looks like an answer until you try to write it into a statement of work. OWASP publishes standards and maturity models. “OWASP compliant” names no standard, no version, no level and nobody who checked. Ask for a third-party assessment against a named standard, then read its scope, method and evidence.
Software development security splits into three layers, and a buyer and a vendor can each be talking about a different one.
| Layer | What it governs | What you can cite | |
| Code | How this application is built and verified |
|
|
| Process | How the team works across releases, not just this one | Practices in the NIST Secure Software Development Framework, published as SP 800-218 | |
| Product and applicable obligations | What the finished product has to achieve | Law (the Cyber Resilience Act, sector-specific law), and contractual standards such as PCI DSS where they apply |
OWASP SAMM measures how mature a supplier’s security practice is as an organization. That helps build a shortlist and fails as an acceptance criterion: maturity is a property of the supplier, while your obligation attaches to the product.
ASVS defines verification levels, so “verified against ASVS Level 2 for the authenticated application” is a testable criterion with a defined scope. Law names outcomes and leaves the method open. Secure coding alone does not show that every applicable regulatory requirement is met, and no regulation will tell your team how to write a query.
Who owns the risk and the remediation when a vendor writes the code
If the product is placed on the EU market, the Cyber Resilience Act assigns obligations to the manufacturer. The Commission’s guidance on Regulation (EU) 2024/2847 states the test plainly at paragraph 71:
“a manufacturer, by definition, is the natural or legal person who places products with digital elements on the market (‘markets them’) under its own name or trademark”
If you market the product under your own name or trademark, the CRA’s definition points to you as the manufacturer, not whoever wrote the code. Whether the Regulation applies to your product is a scope question.
For remote data processing solutions, the guidance is explicit about software built to order. Under paragraph 196, a manufacturer who designs and develops a solution operated by a third party stays responsible for its essential requirements. Paragraph 195 calls such software “built solely by or on behalf of the manufacturer, based on designs and specifications provided by it.”
The contract can allocate the work and the cost of meeting those obligations. It does not, by itself, change which party bears them under the CRA. Three clauses to require:
- Who produces each piece of technical documentation, and by when
- Who performs remediation after acceptance, and at whose cost
- Who handles vulnerability reports, within what window, when a flaw surfaces in a component the vendor selected
For products in scope, the timing is already partly live:
- Reporting obligations for actively exploited vulnerabilities and severe incidents, under Article 14, have applied since 11 September 2026
- The Regulation’s main requirements apply from 11 December 2027
None of this is legal advice, and the scope question deserves a lawyer. BSI, the German federal authority, maintains a scope overview worth reading if you are unsure whether your product is in scope.
From our CTO
Vitaliy Svyrydov, CTO at Corpsoft Solutions, on the requirement most specifications leave out:
“Most specifications leave out requirements for data: where personal data is stored, who can see it, how it gets deleted. Logging of actions, access separation, and sign-in through corporate accounts follow close behind. All of this gets remembered when the first major client sends a security questionnaire — and building it into a finished system costs more than specifying it from the start.”
Compliance designed into the architecture or added later
Some security requirements are features. Others are shapes. The second kind cannot be added at acceptance, because adding them means rebuilding the thing you just accepted.
Corpsoft Solutions’ Compliance-Native Architecture is the practice of deriving architectural decisions from the regulatory requirement before design begins, so evidence becomes a byproduct of how the system runs. The following four web application security requirements illustrate why some decisions have to be made before design starts.
| Requirement | Why it resists late addition | What to specify before design |
| Audit log of user and administrator actions | Retrofitting means instrumenting code paths already in production, and accepting a blind spot for every release before that | Which actions are logged, which fields each entry carries, how long entries are kept, and who can query them |
| Tenant isolation | Isolation enforced inside application code has to be re-proven on every new query anyone writes | Where the boundary is enforced, and the test that proves a cross-tenant read fails |
| Data residency | A late change of region can force a review of services, backups, logs and dependencies | Which regions hold which data categories, including backups and logs |
| Boundaries of personal data processing | If data that was never minimized already reaches several systems and copies, removing it means more changes and more verification | Which fields are collected, where they flow, and which third parties receive them |
Here the secure software development process stops being the vendor’s internal matter. Requirements of this kind belong in the specification you approve, because no vendor can infer your regulatory obligations from a feature list.
The same reasoning applies to the components you inherit without writing, which is the subject of our guide to Third-party software security assessment.
Acceptance criteria you can test
An acceptance criterion is a sentence a third party can evaluate without asking either of you what it meant. “Follows software development security best practices” fails that test. So does “no known vulnerabilities,” which depends on who was looking and how hard.
Use the table below as a software development security checklist for the acceptance section of the contract. Name the ASVS version deliberately, because the criterion inherits whatever that version says; the project page currently points to 5.0.0 as the latest stable release.
| Criterion | How it is verified | Artifact you receive |
| Verified against OWASP ASVS, named version, at Level 2 for the agreed application scope; every applicable requirement assessed, exclusions documented with a rationale | Assessment by a party that did not write the code | Report listing the method, each requirement assessed, the findings, and the documented exclusions |
| No critical or high findings open at delivery under the agreed severity-rating method; any exception approved by you in writing | Penetration test, then a retest of each finding | Dated retest report, and a signed record of the exceptions |
| Audit log holds the agreed fields for the agreed event types | Agreed queries run against a staging environment holding representative data | Log schema, the list of event types checked, and the query results |
| Every shipped component identified and attributable, with an agreed process for updates when dependencies change | Check against the SBOM minimum elements (NTIA, 2021 baseline; CISA notes a 2026 update), in the agreed format | Machine-readable SBOM, and the written arrangement for updates |
| The receiving team can build and deploy the agreed version from the delivered materials | Control build from the source, the pipeline configuration and the dependency information | Build log, dependency versions, and a list of external or vendor-controlled services |
| Vendor access removed on completion | Access review performed on the handover date | Access review record, signed by both sides |
Where PCI DSS applies, Requirement 6.2.4 calls for software engineering techniques or other methods to be defined and used to prevent or mitigate common attacks and related vulnerabilities in bespoke and custom software. It does not prescribe one universal checklist for every development project.
For criteria that rest on a report, our article on SOC 2 Type II compliance covers what an auditor expects a system to be able to do.
From our CTO
On what changes once security is built into the architecture from day one:
“We deliver a product that is ready for audits and enterprise due diligence from day one: security is built into the architecture and verified. After launch, we keep maintaining the system — updating dependencies, closing vulnerabilities, adapting the product to new requirements. The client doesn’t need to keep a separate team for that.”
What belongs in the handover package, and who owns the source code
Handover is where optimism meets inventory. An item nobody named in writing is an item nobody budgeted time to produce.
List the package in the contract, item by item. Which obligations actually travel when the work moves is a separate question, handled in our overview of IT regulatory compliance services.
- The threat model, and the architecture documentation it refers to
- An SBOM covering every component shipped, against the minimum elements published by NTIA and CISA’s 2026 updates
- The secure software development policy the vendor worked to, and the secure software development lifecycle policy your team inherits for later releases
- Test plans, executed results, and retest confirmations
- Source code, build pipeline configuration, dependency information and the access needed to build and deploy the agreed version, with external or vendor-controlled dependencies named
- A complete access inventory, plus the record of removal on completion
- Written assignment of intellectual property rights
Software development IP security starts as a contract question: the buyer needs the rights, source code and access required to maintain and develop the product after handover. Code written by the vendor’s subcontractors is where the chain of assignment can break, so ask about it explicitly.
Specify that rights in all delivered code are assigned to you, including work by anyone the vendor engaged, and that the vendor warrants the chain. Then settle the items that live in someone’s head:
- Who holds the signing keys
- Which third-party accounts sit in the vendor’s name
- What happens to those accounts on the final day
From our CTO
On which regulations actually come up in client conversations:
“The most common question is about GDPR: where the data lives and who the subprocessors are. Fintech clients come with DORA requirements — audit rights, incident notification, an exit plan. NIS2 arrives through supplier questionnaires. The CRA comes up rarely, mostly when there’s a mobile or installable application involved.”
What to require in the RFP for secure custom software development
Everything above, compressed into what to ask for before award. Two public sources do most of the work here, and neither one is a template you can paste.
The Secure by Demand guide, published by CISA, organizes the buyer’s job by procurement stage:
- Before procurement, putting questions to candidate manufacturers about their product security approach
- During procurement, integrating product security requirements into contract language, as appropriate
- Following procurement, continually assessing manufacturers’ product security and security outcomes
Note where the contract sits: in the middle stage, between the questions you put to candidates and the assessment you keep making afterwards.
The OWASP Secure Software Contract Annex is useful as a catalog of topics a security-aware contract should cover, with three caveats that belong in the same breath as the recommendation:
- The document carries no version number and no date, so you cannot tell what it reflects
- The OWASP legal project that hosts it is listed as inactive
- The document itself advises you to involve a lawyer, which is the correct advice and also a limit on its use as a template
Five questions to put to every candidate before award:
- Which audits have you supported, and which artifacts did you produce for them?
- Which of our requirements are architectural, and which can still be added after the first release?
- Who performs remediation when a finding appears after acceptance, and at whose cost?
- What will the handover package contain, listed item by item?
- Who owns code written by your subcontractors, and how is that assignment documented?
A supplier who can explain which requirements are architectural and who owns the subcontractors’ code gives you better evidence than a longer certification list.
If the contract is already signed
If you are past signature, the checklist above becomes a gap list: the work is to measure the distance between what you claim and what you can evidence today, before an enterprise customer or an auditor sets the date for you.
Corpsoft Solutions’ 7-Day Risk Assessment covers that ground from the technical side: an architecture deep-dive and a gap analysis, ending in a prioritized remediation roadmap. It answers one question. Which of your current requirements are provable with artifacts that already exist, and which are claims?
Related questions worth exploring
- Which tools already in your stack create compliance risk before your own code does? Our developer’s guide to third-party compliance risk in SaaS works through the common offenders.
- What happens to the requirements a project keeps postponing? That is the subject of our article on compliance debt
Sources and verification
- Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252, dated Brussels, 27 July 2026. Paragraph 71 on the manufacturer; 195 and 196, in the section on remote data processing solutions; 210, which states that the obligation to comply with Article 14 applies from 11 September 2026 to all products in scope; 33, on the Regulation entering into application on 11 December 2027. Announcement and policy page.
- BSI Cyber Resilience Act pages, German federal authority, used here for scope only.
- PCI DSS v4.0.1, Requirement 6.2.4, which names an outcome and names no vulnerability catalog.
- OWASP ASVS, whose project page names 5.0.0 as the latest stable version with no release date given, and OWASP SAMM.
- NIST SSDF and SP 800-218.
- NTIA minimum elements for an SBOM, 2021. The CISA SBOM page carries a section headed “2026 Updates to Minimum Elements for a Software Bill of Materials (SBOM)”.
- Secure by Demand guide, published by CISA.
- OWASP Secure Software Contract Annex, undated, hosted by a project listed as inactive.
All links verified 20 October 2026.
Share this post:
