Public accountability in cybersecurity comes down to one thing: security claims that people outside the organization can check. A patch policy, a breach notification, a procurement contract, a management attestation — each counts as accountable when four conditions hold. Somebody is named as responsible. A deadline is attached. An outsider can verify whether the deadline was met. And something actually happens when it wasn’t. Four conditions. It’s worth noticing how few security claims you’ve read this month meet even two of them.
Everything else in this piece — disclosure policies, transparency reports, statutory response clocks, reproducible builds — hangs off that structure. And the structure is why this matters to the people who read this blog, because almost none of you can audit code yourselves. A journalist staring down commercial spyware, a shop owner picking up supply-chain duties under the EU’s NIS2 Directive, an activist fighting a municipal surveillance purchase: all three depend on the same thing. Documents and deadlines they can hold up in public. That’s the difference between security as a vendor promise and security as a civic practice, and it’s the reason this site exists.
What public accountability means — and what it is not
Accountability is a structure, not a tone. CISA’s patch directives are accountable because they name who must act, set a clock, publish the list you check against, and carry consequences inside the agency when the clock runs out. Now take the sentence buyers see most often — “we take security seriously.” None of the four conditions. It isn’t a weaker version of accountability; it’s the opposite of it.
Plenty of what passes for assurance fails the same test. A SOC 2 Type II report usually travels under NDA, so the only people who can check it are already contractually close to the vendor. An ISO/IEC 27001 certificate is public, fine, but its whole meaning lives in the scope statement — and a scope like “data center operations in one country” says nothing about the mobile app your staff actually carry around. The fix isn’t to reject audits. The fix is to demand the parts a stranger can be shown.
Public accountability isn’t full disclosure, either. Coordinated vulnerability disclosure, laid out in ISO/IEC 29147, is the accountable standard precisely because it commits an organization to a named contact and timelines rather than to publishing exploitation details. And publishing your own network architecture, or the identities of your security staff, isn’t accountability — it’s a gift to attackers. The object of the exercise is a checkable process record, not a bigger attack surface.
The deadlines that are already running
Here’s my problem with how urgency usually gets manufactured in this field: it comes from threat actors, the scarier the better. Real urgency comes from calendars. Patch windows, reauthorization votes, procurement hearings, statutory response clocks — they run whether anyone watches or not. Public accountability is how the rest of us get to watch. These are the clocks that matter most to readers in the EU and North America right now.
Statutory response clocks in the EU
Under Article 33 of the GDPR, a data controller must notify its supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the individuals concerned — and any delay has to come with reasons attached. Processors carry their own duty under Article 33(2): inform the controller “without undue delay.” This is a clock you can check from the outside. When a vendor tells you about an incident, ask when they became aware. The answer is a date. Dates can be compared. What Article 33 doesn’t cover: breaches involving no personal data, and the separate Article 34 duty toward affected individuals, which runs on “without undue delay” rather than a fixed hour count.
NIS2 turned the pressure up for essential and important entities. Article 23 sets a three-stage clock for significant incidents: an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within one month. Article 20 attaches personal consequences — management bodies must approve the cybersecurity risk-management measures and oversee their implementation, they can be held liable for infringements, and they’re required to get training. Member states had until 17 October 2024 to transpose the directive, which means the operative text for your organization is your national law. Read that one, not a summary, because transposition details differ from country to country. The directive itself is the reference for what your national statute is supposed to contain.
One more date, for anyone selling products with digital elements in the EU: the Cyber Resilience Act (Regulation (EU) 2024/2847) schedules vulnerability and incident reporting duties — including a 24-hour report to ENISA for actively exploited vulnerabilities — from September 2026, with the main obligations applying from 11 December 2027. If you ship software or connected hardware, those dates belong in your product calendar now. Not in 2027.
Patch windows in the United States
In the US, CISA’s Binding Operational Directive 22-01 orders federal civilian agencies to remediate vulnerabilities on the Known Exploited Vulnerabilities (KEV) catalog on fixed clocks: two weeks for entries with a CVSS score of 9.0 or above, with longer fixed windows for lower scores. State the limit plainly, because it gets misread constantly: this directive binds agencies, not private companies. But the catalog is public, it’s published in machine-readable form, and nothing stops your organization from adopting it as a free, checkable patch priority list. Pair it with the Exploit Prediction Scoring System (EPSS), an open scoring model published by FIRST, and you have a triage method traceable to public documents instead of a vendor’s severity labels.
Reauthorization votes and procurement hearings
Some accountability moments are scheduled years in advance. The US Congress renewed Section 702 of FISA in April 2024 with a sunset in April 2026, and between now and that vote, every member of Congress holds an accountable position you can ask about in writing. Procurement is the other scheduled forum. In the EU, contract award notices are published in the Tenders Electronic Daily database, and EU institutions answer to Regulation (EC) No 1049/2001 on public access to documents. In the US, the Freedom of Information Act gives agencies 20 business days to respond, and state sunshine laws set their own clocks. When the European Parliament’s PEGA committee published its findings on spyware use against EU citizens in March 2023, it was these mechanisms — hearings, document requests, published records — that turned rumor into a public record. Not covered: national-security exemptions narrow every one of these paths, and a denial that cites an exemption is itself data about where oversight currently stops.
Why vendor promises fail and documents hold
A promise fails the four conditions. A document can pass them. The artifacts worth asking for, and checking, include:
- A disclosure policy aligned with ISO/IEC 29147, with a named contact and committed response timelines — made machine-findable through a security.txt file at the well-known location defined in RFC 9116.
- A dated public changelog or release feed, so anyone can verify whether a vendor met its own patch window.
- A software bill of materials (SBOM) in SPDX (standardized as ISO/IEC 5962) or CycloneDX (an OWASP standard) format, listing the components of the exact artifact you run. That lets you match public CVE records against your dependencies yourself, instead of waiting for a vendor’s email. US federal software suppliers have been expected to provide SBOMs since the May 2021 federal cybersecurity executive order pushed them into procurement, and the Cyber Resilience Act will make component transparency a product requirement in the EU.
- A transparency report with counts — government requests received, warrants challenged, canaries published — that can be compared year over year.
- Reproducible builds, the strongest form of public accountability in shipping software: anyone can rebuild the shipped binary from public source and compare the results. Signal publishes reproducible builds for its Android client, and the Debian project has run a multi-year reproducible-builds effort across its archive. You don’t have to perform the rebuild yourself. The point is that an independent party can, and that claim is checkable in a way no marketing sentence is.
None of this is free, and honest vendors say so. Changelogs tell attackers what changed. Disclosure timelines get abused by researchers chasing attention faster than fixes get written. The accountable middle path is coordinated disclosure and dated, delayed detail: publish the process record, not the exploitation recipe. I’ve sat on the buyer’s side of enough procurement calls to notice that the vendors who acknowledge this tradeoff openly are, more often than not, the ones whose other documents hold up too. Small sample, but it keeps proving itself.
What accountability looks like for three kinds of reader
Journalists: spyware is a procurement story
The Pegasus and Predator cases were not broken by intuition. They were broken by forensic work from teams like Citizen Lab, then carried by procurement records, parliamentary inquiries, and export-control decisions — including the US Commerce Department’s 2021 Entity List designation of NSO Group. When you report on surveillance technology, follow the paperwork. Which budget line. Which contract. Which oversight body signed. Which statutory clock was missed. Then apply the same standard to your own newsroom: publish a patch policy with dates and a named owner, and keep your architecture private. A newsroom that demands accountability from vendors while offering none of its own has no standing to ask.
Small-business owners: procurement is your hearing
You can’t audit a vendor’s code. You can audit their answers in writing before you sign, and in practice that’s the stronger position. Article 21(2)(d) of NIS2 names supply-chain security — including obligations spread across the chain of contracts — among the risk-management measures essential and important entities must take. Translation: your larger customers will soon send you the same questions you should be sending your suppliers. Keep a dated file of who you asked, what you asked, what they answered, and when. If something breaks two years from now, that file is your defense. It costs an afternoon to start.
Activists: records requests are security work
The surveillance tools used in your community were bought by a public body, from a company, under a signed contract. FOIA and state sunshine laws in the US, and Regulation (EC) No 1049/2001 for EU institutions, exist to surface those documents — and the federal FOIA clock runs 20 business days. Ask for contracts, invoices, purchase orders, training records, oversight correspondence. Expect exemptions, and count them. A pattern of denials under the same exemption is a finding you can publish, and it marks precisely where public oversight currently ends.
Five questions that turn a promise into a checkable claim
Use these in your next renewal negotiation or procurement email. Each one converts a vibe into a document.
- Where is your vulnerability disclosure policy, and who answers reports? A policy aligned with ISO/IEC 29147 names a contact and commits to timelines; a security.txt file per RFC 9116 makes the contact machine-findable.
- What is your patch service level, in writing, and where do you announce releases? “As soon as possible” is not a service level. A dated public changelog is checkable.
- Can you provide an SBOM in SPDX or CycloneDX for the exact version we run? If the answer is no, ask what they can provide, and log the answer with a date.
- Which incidents start a statutory clock on your side, and how fast will you tell us? A competent answer names Article 33(2) of the GDPR and the NIS2 early-warning clock without being prompted.
- What exactly does your ISO 27001 certificate cover, and what can you share publicly? The scope statement is the entire meaning of the certificate. If the full report sits under NDA, ask which parts can be published — the answer is itself accountability data.
What this article does not cover
- This isn’t legal advice. For incident handling, talk to a lawyer and to your national data protection authority; the clocks above are statutory, and misreading one has consequences.
- National transpositions of NIS2 differ. Read your member state’s statute rather than relying on this summary.
- Certifications aren’t worthless. They’re evidence with a scope. The accountability gap lies in what can’t be shown publicly, not in the audits themselves.
- Secure development practice is its own discipline; NIST SP 800-218, the Secure Software Development Framework, is the primary reference, and it deserves its own article.
- Classified and national-security procurement sits largely outside every mechanism described here. That exemption zone is a live political question, not a settled one.
Your step for today: twenty minutes, one vendor
Pick one software vendor you currently pay. Spend ten minutes checking: does https://their-domain/.well-known/security.txt exist, does their site carry a disclosure policy with a named contact, and do their products show up in the public KEV catalog or in CVE records? Spend the next ten sending one email with questions 1 and 2 above, and log the send date. Whatever comes back — an answer, a deflection, silence — goes in your dated file. You’ve just produced the smallest unit of public accountability: a claim, a clock, and a record.
This article also opens a recurring column on this blog: The Paper Trail. Once a month, we’ll take one primary document — a directive, a scope statement, a disclosure policy, a records-request denial — and read it in public, line by line. The next installment reads a real SBOM and shows exactly what its fields do and don’t tell you. If you have a vendor policy you can’t parse, send it in; reader submissions set the queue.
Frequently asked questions
What is public accountability in cybersecurity?
It’s the practice of making security claims checkable from outside the organization making them. A claim is accountable when a named party is responsible, a deadline is attached, an outsider can verify whether the deadline was met, and a consequence follows when it wasn’t. Published patch policies, ISO/IEC 29147-aligned disclosure policies, statutory breach clocks, transparency reports, and reproducible builds are all examples.
What is the 72-hour rule?
Article 33 of the GDPR requires a data controller to notify its supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals; delays must be justified with reasons. NIS2 runs a parallel clock for significant incidents at essential and important entities: a 24-hour early warning and a 72-hour incident notification.
How quickly must US federal agencies patch known exploited vulnerabilities?
Under CISA’s Binding Operational Directive 22-01, federal civilian agencies must remediate vulnerabilities on the Known Exploited Vulnerabilities catalog within fixed windows — two weeks for entries scored CVSS 9.0 or above, with longer fixed windows for lower scores. The directive doesn’t bind private organizations, but the catalog is public data any organization can adopt as a patch priority list.
What is an SBOM, and why does it create accountability?
A software bill of materials lists the components in a specific software artifact, in a standard format such as SPDX (ISO/IEC 5962) or CycloneDX. It lets a buyer match public CVE records against their own dependencies directly, instead of relying on the vendor’s severity claims or waiting for an email.
Can SOC 2 reports or ISO 27001 certificates be checked publicly?
Generally, no. SOC 2 reports are typically shared under NDA, and an ISO 27001 certificate only shows that a defined scope was audited — the scope statement, not the logo, carries the meaning. Ask vendors what portion of their evidence they can publish; the answer is itself accountability data.
Deadlines don’t wait, and neither should your file. Pick your vendor, send the email, start the record today.