Two questions, in order. Does checking for security at the end of a build actually work? And if not, what has to happen instead?
CVE-1999-0001, the first entry in the Common Vulnerabilities and Exposures list, the public registry where disclosed software vulnerabilities get logged, was the first vulnerability ever recorded there. One entry. In 2025, that database logged 48,185 new ones in a single year, a record, up more than 20% on the year before, according to JerryGamblin's 2025 CVE Data Review. The attack surface didn't grow. It exploded, and most of it traces back to security requirements nobody wrote down.
Regulation grew with it, but slower, and then suddenly not slower at all. GDPR arrived in 2018 with a principle: build in privacy by design. It was law, but it read like good advice with a penalty attached. Then came NIS2, binding since October 2024, and the Cyber Resilience Act, phasing in through December 2027. These don’t read like advice. NIS2 puts executives personally on the hook for cybersecurity risk-management failures, according to the European Commission. The Cyber Resilience Act goes further: from December 2027, a product without a CE mark showing it was built secure from the start cannot legally be sold anywhere in the EU, according to the European Commission’s own CRA summary. Not a fine. Not a warning. No market access at all.
A hospital rolled out a new patient portal last year. Three weeks in, a researcher found that changing one number in the browser’s address bar pulled up another patient’s records. The requirements document had a line for ‘patient login.’ It had no line for what the login was allowed to expose. Nobody had written that part down, so nobody built it.
Does checking for security at the end actually work?
No, and the reason is structural, not a matter of effort. A requirements document tells engineers what to build. If it doesn’t say what the software must never do, exposing data, skipping an audit trail, missing an encryption standard, then nothing downstream is checking for those things either. Testing catches bugs against a specification. It cannot catch the absence of a rule that was never written.
This is the gap between ‘test for security before shipping’ and ‘specify security before building,’ and most enterprises are still doing the first one. It looks like diligence. It produces a penetration test report a week before launch, a list of findings, and a scramble to patch what the architecture already assumes. By then the data model is set, the third-party integrations are wired in, and half the findings get a waiver instead of a fix, because rebuilding is expensive and the launch date isn’t moving.
The European Commission’s own reasoning for the original 2022 Cyber Resilience Act proposal cited findings that roughly 60% of products on the market shipped with known vulnerabilities already in them at launch, and that two-thirds of cyberattacks trace back to a vulnerability that could have been designed out. “Europe is only as strong as its weakest link,” Thierry Breton, the EU’s Commissioner for the Internal Market, said when the Cyber Resilience Act was proposed. He wasn’t talking about cost. He was talking about which products get to exist in the European market at all.
What does specifying it at requirements time actually look like?
Not a longer requirements document. A different one, with security and compliance people in the room while it’s being written, not reviewing it after.
- Write the constraint next to the feature, not in a separate document nobody reads. ‘Users can reset their password’ sits beside ‘reset tokens expire in 15 minutes and are logged with a timestamp and requester ID,’ because the second line is what NIS2’s incident-reporting obligations actually require, and it cannot be reverse-engineered from working code after the fact.
- Name the regulation the requirement comes from. Not ‘encrypt sensitive data’ but ‘encrypt data in transit and at rest, per Cyber Resilience Act Annex I, because this product ships with a network connection.’ A requirement with no named source is the first one cut when the deadline moves.
- Put someone who understands the regulation in the requirements review, not just the security review. By the time a compliance officer sees a specification, the architecture is usually already chosen, and by then ‘add this’ always means ‘rebuild this.’
- Treat the requirements document as the evidence, not just the plan. Under the CRA, manufacturers have to demonstrate how a product meets its essential requirements. A requirements document that already states the constraint and its regulatory source is most of that evidence, written once, not reconstructed under a deadline before an audit.
This is the layer Calsoft’s AI-Driven Compliance practice is built for: continuous control monitoring and evidence automation that keeps proving a requirement is still true long after launch, rather than a one-time check before it. Once a constraint is written into the requirements, this is how you show, on an ongoing basis, that the system still honors it, not just that it did on the day someone signed off.
The hospital in that story eventually fixed the access-control bug. The fix took an afternoon. Rebuilding trust with the patients whose records were exposed took considerably longer, and no patch touches that part.
The companies that treat this well in 2027 won’t be the ones who passed their compliance review. They’ll be the ones for whom the review found nothing to say, because the requirements already said it first.
FAQs
Why should security requirements be defined early in the SDLC?
Testing only checks what was built against a spec. If security requirements never appear in that spec, nothing downstream catches their absence. Under the Cyber Resilience Act, a missing requirement isn't a bug found late, it's a compliance gap that can block a product from the EU market entirely.
How do you turn compliance requirements into software requirements?
Write the regulation's language directly into the spec, not as a footnote. Instead of "encrypt sensitive data," write "encrypt data in transit and at rest, per Cyber Resilience Act Annex I." A requirement with no named regulatory source is usually the first one cut when a deadline moves.
How do you maintain security and compliance requirements as regulations change?
Treat the requirements document as living evidence, not a one-time sign-off. NIS2 and the Cyber Resilience Act phase in obligations over several years, so continuous monitoring, not periodic review, is what shows a system still meets a requirement after the regulation behind it changes.
