Which security standards actually apply to you?

The question a security executive answers before funding anything, and the one buried under encyclopedias that explain what each standard says rather than whether it applies to you.

Take a copy: markdown or Word document. Every file, both formats. Interactive version: https://wshallwshall.github.io/secure-development-standards/standards/WHICH-STANDARDS-APPLY.html – written out in full, because a relative link is dead in a downloaded Word file.


TLDR/BLUF

Most standards writing explains what each document says. The question you actually have is which of them reach you at all, and that is the one this page answers. It routes and carries no reference table: one question, answered at least twelve ways, every answer pointing into the reference, which holds one row per document and the reasoning behind the cuts it sorts on.

Work it in three steps:

  1. Answer the routing questions below for your own situation – or use the selector, if you are reading this on the served site rather than in a downloaded copy.
  2. Take every answer to its row in the reference, which carries what that document issues, what triggers it, the status with the date it was checked, and a check you can run yourself.
  3. Read the result as a floor, not a list. “At least these” is the only claim available here, so matching nothing is not evidence that nothing applies – the gaps are named on purpose.

None of it says you must comply. That a document applies to your situation does not mean it binds you; a clause in a contract, a statute or a procurement rule decides that, and nothing here is legal advice.

The served page adds a selector above the routing table. It only hides rows: it computes nothing and holds no fact this document does not. A downloaded copy gives you the same routing unfiltered – printable, forwardable to counsel, markable.


Work out which of these may apply to your situation

The list below starts unfiltered, which is its resting position -- you do not have to touch a control to get the full unfiltered list. Nothing here needs you to know a standard's name.

What may apply to your situation

Showing all of the at least 40 items mapped here, unfiltered. This is not a list of what applies to your situation.

Arrives without anyone asking

Binds a producer directly, if the trigger below describes what you ship. No customer has to ask, and no contract has to name it.

EU Cyber Resilience Act, Regulation (EU) 2024/2847

Makes demands of a software producer

The only item mapped here that binds a producer directly, with no customer asking.

Only if you place a product on the EU market.

What it issues
A declaration of conformity and a mark you affix yourself after your own assessment. Some product classes require a notified body.
What triggers it
Placing a product with digital elements on the EU market. The trigger is where the product goes, not who buys it.
Status, checked 2026-08-06
In force 2024-12-10. Reporting obligations apply from 2026-09-11, ahead of the rest of it; the main body of obligations from 2027-12-11.
The check you can run without trusting this page

Routinely treated as something a customer asks for. It is a market-access rule you satisfy before you ship, and the owner is engineering and release, not the compliance function.

This document's section in the reference table

May apply to your situation, and how

Each row carries the route it arrives by, what it issues, and when its status was checked.

CISA 2026 Minimum Elements for an SBOM

Makes demands of a software producer

A field definition that states in its own text that it creates no new requirements.

What it issues
Nothing. It defines fields, states that it creates no new requirements, and places accuracy, coverage and completeness out of its own scope.
What triggers it
A contract term requiring an SBOM. In US federal contracting that is now each agency's own choice.
Status, checked 2026-08-06
Published 2026-07-29, replacing the minimum elements of 2021-07-12.
The check you can run without trusting this page

"Generate SBOMs to the NTIA 2021 minimum elements." Those were replaced on 2026-07-29. Separately, a conforming SBOM can still be inaccurate and incomplete -- the 2026 elements say so themselves and point at a signature, at binary analysis, and at exploitability advisories as separate mechanisms.

This document's section in the reference table

CISA Secure Software Development Attestation Form

Makes demands of a software producer

A signed self-attestation whose government-wide collection mandate was rescinded while the form itself survived.

What it issues
A self-attestation signed by an executive, or, on an alternative route the form itself permits, a third-party assessment attached in place of the signature. Not a certificate and not an audit.
What triggers it
An individual agency's contract term or request.
Status, checked 2026-08-06
Still published, with clearance to 2027-03-31. Optional for agencies since the memoranda requiring it were rescinded on 2026-01-23.
The check you can run without trusting this page

"Sign the federal attestation form to sell software to the US government." The memoranda requiring agencies to collect it were rescinded on 2026-01-23. Agencies may still ask; none must. Read the rescinding memorandum at the publisher, then read your own contract's clauses.

EO 14028 (2021) directed the guidance. OMB M-22-18 and M-23-16 turned it into a collection requirement. EO 14144 in January 2025 would have added submission to a repository, central verification and referral of failures, and EO 14306 struck that apparatus on 2025-06-06. OMB M-26-05 then rescinded the collection mandate itself on 2026-01-23. Anyone describing a single January 2026 event has lost the fact that the verification model was already gone in mid-2025. The status of the federal repository that received submissions is unknown as of the check date: not reported running, not reported gone.

This document's section in the reference table

CWE Top 25, 2025 edition

Makes demands of a software producer -- a ranking, not a requirement set

A ranking of weakness classes, occasionally named in procurement language.

What it issues
Nothing.
What triggers it
A policy or questionnaire naming it, and occasionally procurement language asking for coverage.
Status, checked 2026-08-06
2025 edition announced 2025-12-11, project page updated 2026-01-29. Any reference to a 2026 edition is unconfirmed.
The check you can run without trusting this page

Same completion-condition problem as any ranking: it cannot be discharged as written.

This document's section in the reference table

HITRUST CSF (e1, i1, r2)

Makes demands of an organization, not a product

A third-party validated assessment that an organization's controls and environment meet the framework. Explicitly not a software product certification.

What it issues
A validated assessment result for an organization. There is no path by which distributable software is certified; the environment operating it can be.
What triggers it
A customer or procurement requirement naming it. The sources behind this page state no independent trigger, so confirm it in the contract.
Status, checked 2026-08-06
Three tiers, and they are not interchangeable: e1 (essentials, one year, foundational controls), i1 (one year, established programs, middle assurance), r2 (highest, tailored and risk-based, for complex environments). The tier detail rests on secondary sources; verify anything more specific than the tier names and the scope-variance point at the publisher.
The check you can run without trusting this page

Which tier, and what was in scope. "We are certified" stated without both tells a reader very little: scope drives control count enormously, and the same highest-tier result can be a few hundred controls for one organization and a few thousand for another.

This document's section in the reference table

ISO/IEC 27001:2022 (plus Amendment 1:2024)

Makes demands of an organization, not a product

A certification of an information security management system, not of a product and not of a codebase.

What it issues
A third-party certificate from a certification body, for a stated scope. ISO itself issues nothing.
What triggers it
A customer or procurement requirement, most often in vendor onboarding.
Status, checked 2026-08-06
Published 2022-10; Amendment 1 published 2024-02-23. The 2013-edition transition ended 2025-10-31, per secondary reporting.
The check you can run without trusting this page

Read the scope statement on the certificate. A certificate whose scope covers one office or one business unit is common, and is not what the reader assumes. Called "the international SOC 2" universally, and it is a different instrument with a different failure mode: SOC 2 gives you an opinion plus exceptions, this gives you a certificate plus a scope statement.

This document's section in the reference table

ISO/IEC 27002:2022

Makes demands of an organization, not a product

Implementation guidance for the controls the certifiable standard lists. Not itself certifiable.

What it issues
Nothing. It explains how to implement the controls the certifiable standard lists.
What triggers it
No independent trigger. It arrives beside a certification program, or in error on a questionnaire.
Status, checked 2026-08-06
Published 2022-02. It received a climate-related amendment in the same 2024 cycle; the designation was not confirmed.
The check you can run without trusting this page

Named on a questionnaire as though a supplier could be certified or attest to it. Conformance to a guide is not a thing that exists.

This document's section in the reference table

ISO/IEC 5055:2021 and OMG ASCQM 1.1

Makes demands of a software producer

One family of automated source code measures published in two venues, not two separate obligations.

What it issues
Nothing. Defined counts of severe structural weaknesses, once a tool implements them.
What triggers it
An enterprise or supplier contract specifying automated source code measures.
Status, checked 2026-08-06
ISO adoption announced 2021-04-07; ASCQM 1.1 formal since July 2022. One measure family in two venues, not two obligations.
The check you can run without trusting this page

Read as two separate requirements because it appears under two publisher names.

This document's section in the reference table

NIST SP 800-218 v1.1 (SSDF)

Makes demands of a software producer

A secure software development framework with no conformance machinery attached to it.

What it issues
Nothing. No conformance criteria, no levels, no assessment procedure.
What triggers it
A contract clause, an agency assurance policy, or a questionnaire quoting practice identifiers.
Status, checked 2026-08-06
Final since 2022-02-03 and not withdrawn. A draft successor, SP 800-218r1 (v1.2), has been open since 2025-12-17 and is not final.
The check you can run without trusting this page

"Map controls to the current SSDF, or to SSDF 1.2." v1.1 of 2022 is the only final version. The publisher's own publications listing shows Final against one and Draft against the other.

This document's section in the reference table

NIST SP 800-218A (SSDF community profile for AI models)

Makes demands of a software producer

A profile about producing AI models, routinely misfiled as guidance for developers using AI coding assistants.

What it issues
Nothing.
What triggers it
Building or fine-tuning generative AI or dual-use foundation models, when a contract names it.
Status, checked 2026-08-06
Final 2024-07-26. The executive order that commissioned it was revoked 2025-01-20; the publication itself stands.
The check you can run without trusting this page

Its declared scope is producing AI models. Its single sentence on assisted code says the practices do not distinguish it from human-written code, which is a scoping exclusion rather than guidance. Search the publication for that sentence -- it is the whole of the coverage.

This document's section in the reference table

NIST control overlays for securing AI systems

Makes demands of an organization, not a product

In development. Named here because it is the item people expect to exist, and it does not yet.

What it issues
Nothing today.
What triggers it
Nothing today.
Status, checked 2026-08-06
In development, with no draft overlay published as of the check date, so nothing can be aligned with them today.
The check you can run without trusting this page

Cited in roadmaps as though alignment were possible now. No draft exists to align with.

This document's section in the reference table

OWASP ASVS 5.0.0

Makes demands of a software producer

A verification requirement set that certifies nobody, by its own statement.

What it issues
Nothing. Its own assessment chapter states that OWASP certifies no vendor or software.
What triggers it
A customer contract or questionnaire naming a verification level.
Status, checked 2026-08-06
Released 2025-05-30, superseding 4.0.3 of 2021-10-28. Identifiers were reorganized rather than carried across.
The check you can run without trusting this page

Cited as though a level could be certified. Identifiers from the prior edition do not carry across either, so a policy quoting an old identifier resolves to something different or to nothing.

This document's section in the reference table

OWASP Top 10 for LLM Applications, 2026 edition

Makes demands of a software producer -- a ranking, not a requirement set

A ranking about securing an application that calls a language model at run time.

What it issues
Nothing.
What triggers it
An AI feature review, a customer AI questionnaire, or an internal policy naming it.
Status, checked 2026-08-06
Dated 2026-08-03 on the project's own resource page, with press coverage on 2026-08-04. The prior edition dates from 2024-11-18.
The check you can run without trusting this page

Offered as governance for what an AI coding assistant writes for you. It addresses securing an application that calls a language model at run time, which is a different subject, and the two are conflated constantly.

This document's section in the reference table

OWASP Top 10:2025

Makes demands of a software producer -- a ranking, not a requirement set

An awareness ranking, by its publisher's own description.

What it issues
Nothing. OWASP calls it an awareness document.
What triggers it
A contract clause or questionnaire saying a product was tested against it, and scanner report headings.
Status, checked 2026-08-06
The 2025 edition is current on the project's own page, which stamps no final publication date. A release candidate in November 2025 and finalization in January 2026, per secondary coverage. Two categories are new, and an older category was absorbed into another.
The check you can run without trusting this page

A ranking has no completion condition and cannot be discharged as written. Convert it into a requirement-set clause while the clause is being agreed; by assessment time the only remaining options are to argue or to over-deliver.

This document's section in the reference table

SLSA v1.2

Makes demands of a software producer

Build and source provenance levels that a consumer verifies, with no register and no issuer.

What it issues
Nothing. Machine-readable provenance the consumer verifies. There is no register of levels.
What triggers it
A customer or a package ecosystem asking for build provenance.
Status, checked 2026-08-06
Approved 2025-11-12, released 2025-11-24. It restored a Source track with four levels; there is still no Build L4.
The check you can run without trusting this page

"Require SLSA Level 4." There is no Build L4. Since v1.2 there is a Source L4, so a bare level number no longer identifies a requirement. Read the specification's own track pages and write the track beside the level.

This document's section in the reference table

SOC 2 (Type 1 and Type 2)

Makes demands of an organization, not a product

An examination report on a service organization, carrying an opinion and no pass mark.

What it issues
An examination report carrying a licensed firm's opinion. Restricted use, no pass mark, no certificate.
What triggers it
A customer questionnaire or contract clause, overwhelmingly in US business-to-business sales.
Status, checked 2026-08-06
Criteria are the 2017 Trust Services Criteria with 2022 revised points of focus, posted 2023-09-30. The governing attestation standard applies to reports dated on or after 2022-06-15.
The check you can run without trusting this page

Read the scope statement and the listed exceptions. A report with no exceptions over twelve months is unusual enough to be worth asking about, and the cover page tells you nothing. Type 2 covers operating effectiveness over a period, typically six to twelve months; Type 1 is a point-in-time design opinion only. If what you sell is distributed software rather than a hosted service, the product can sit entirely outside the report's scope boundary.

This document's section in the reference table

FedRAMP

Makes demands of an organization, not a product

A government program status for a cloud service offering, as a condition of a federal sale.

What it issues
A program certification for a service offering, listed publicly. An agency's own authorization stays a separate decision.
What triggers it
Selling a cloud service to a US federal agency.
Status, checked 2026-08-06
Founding 2011 memorandum rescinded 2024-07-25. Phase 3 of the replacement model active since 2026-04. Rev5 intake closes 2027-06-11.
The check you can run without trusting this page

"It is an authorization not a certification, at low, moderate or high, via the JAB or an agency." The program uses certification vocabulary and lettered classes, and the board that granted provisional authorizations no longer does so. Delivering the old correction now makes you the out-of-date party. Read the program's own definitions page.

Assesses a service offering you operate, which is why it sits with the operating organization even though a software company usually pays for it. One cloud program has begun leveraging an external framework for its lightest class only, and calls that class transitory: narrow, and not a shortcut. A discrepancy between one cloud program's claim of recognition by another and that other program's own published outcome is left open here rather than resolved.

This document's section in the reference table

GovRAMP (formerly StateRAMP)

Makes demands of an organization, not a product

A verification status for a service offering, required by some US state, local, tribal and education buyers.

What it issues
A verification status granted by the program office and published on a participants list.
What triggers it
A US state, local, tribal or education procurement requirement, varying by jurisdiction.
Status, checked 2026-08-06
Rebranded 2025-02-14. StateRAMP remains the legal entity name, operating as GovRAMP, so both names are legitimately live.
The check you can run without trusting this page

"Ask the supplier for their StateRAMP status." The program has operated under the new name since 2025-02-14 while the old one remains the legal entity name. A search on one name alone stops working.

This document's section in the reference table

CJIS Security Policy

Makes demands of an organization, not a product

A policy naming contractors within its own scope, audited by the relevant authority rather than certified centrally.

What it issues
No central certificate. An audit by the relevant authority, with the finding landing on the agency.
What triggers it
An agreement giving access to the covered data. The policy names contractors within its own scope.
Status, checked 2026-08-06
v6.0 issued 2024-12-27, v6.1 dated 2026-06-25. Secondary reporting says audits continue against an earlier version; confirm with the auditing authority.
The check you can run without trusting this page

A central certificate is assumed to exist, and the version being audited is assumed to be the newest published one. Confirm the audit baseline with the authority that will actually audit, on the date it will happen.

This document's section in the reference table

FERPA (20 U.S.C. 1232g; 34 CFR Part 99)

Makes demands of an organization, not a product

An education-records statute enforced through federal funding, with no assessor and no registry.

What it issues
Nothing. No certificate, no assessor, no registry. Enforcement runs through federal funding.
What triggers it
Receiving the covered federal funds, or a contract with an institution that does.
Status, checked 2026-08-06
Statute in force since 1974; the regulations were substantially amended in 2008. No status change in the last 24 months.
The check you can run without trusting this page

Sought as a compliance artifact. There is no assessor and no registry to be listed in.

This document's section in the reference table

FTC Safeguards Rule under GLBA (16 CFR Part 314)

Makes demands of an organization, not a product

A written-program requirement whose definition of a covered institution is wider than self-image.

What it issues
Nothing. A written program, a named accountable individual, and a reporting duty.
What triggers it
Meeting the rule's statutory definition of a covered institution, which is wider than self-image.
Status, checked 2026-08-06
Substantive requirements fully effective 2023-06-09. The breach-reporting amendment became effective 2024-05-13.
The check you can run without trusting this page

Organizations that do not think of themselves as financial institutions assume it does not apply to them. The definition is statutory, not a matter of self-description.

This document's section in the reference table

HIPAA Security Rule (45 CFR Part 164 Subpart C)

Makes demands of an organization, not a product

A regulator's rule on a covered organization, which recognizes no certification.

What it issues
Nothing. The enforcing agency has stated since 2003 that it recognizes no certification.
What triggers it
Being a covered organization, or an agreement flowing the obligation down a contract chain.
Status, checked 2026-08-06
In force, operative text unchanged. A proposed overhaul published 2025-01-06 is not final; the projected final action has moved to July 2027, per secondary reporting.
The check you can run without trusting this page

Suppliers are asked to produce a certificate against it. None exists, and the enforcing agency has said so for over twenty years. It also binds an organization, not a product.

This document's section in the reference table

NIS2 Directive ((EU) 2022/2555)

Makes demands of an organization, not a product

An EU directive that binds nobody directly; the obligations come from each member state's transposing law.

What it issues
Nothing at EU level. Obligations, deadlines and penalties come from a member state's transposing law.
What triggers it
Sector plus size thresholds under national law, which has to be tested per member state.
Status, checked 2026-08-06
Transposition was due 2024-10-17 and remains incomplete. The Commission referred four member states to the Court of Justice in 2026.
The check you can run without trusting this page

Read as a single EU-wide obligation with one set of thresholds. It is national law that binds, and transposition is incomplete, so the answer differs by member state and in some cases does not exist yet.

This document's section in the reference table

PCI DSS v4.0.1

Makes demands of an organization, not a product

A payment-chain standard whose validation requirement is set by your acquirer, not by its author.

What it issues
A report or a self-assessment questionnaire, plus a signed attestation. No certificate exists.
What triggers it
An agreement with an acquirer or a brand, arriving through the payment chain rather than a regulator.
Status, checked 2026-08-06
v4.0.1 published 2024-06; v4.0 retired 2024-12-31; the future-dated requirements became mandatory 2025-03-31.
The check you can run without trusting this page

"We are working toward 4.0, and the future-dated requirements are still future." v4.0 retired 2024-12-31, leaving v4.0.1, and the future-dated requirements became mandatory 2025-03-31. The body that writes the standard is not the body that sets your validation requirement.

This document's section in the reference table

SEC cybersecurity disclosure rules (17 CFR Parts 229, 232, 239, 240, 249)

Makes demands of an organization, not a product

A disclosure obligation on registrants, whose output is a filing rather than an assessment. Nothing asked here establishes registrant status -- this is a fact to go and check, never an inference drawn from your answers.

What it issues
Nothing. The output is a filing. No assessor and no examination.
What triggers it
Being a registrant of the relevant class. Nothing about your stack changes the answer.
Status, checked 2026-08-06
Adopted 2023-07-26, effective 2023-09-05. A rescission petition was filed 2025-05-22; no adopting release was found as of the check date.
The check you can run without trusting this page

Treated as a security control requirement that engineering choices can satisfy or avoid. It is a disclosure duty attached to registrant status. Nothing asked here establishes that status, so this is a fact about your organization to go and check, never an inference drawn from your answers.

This document's section in the reference table

The US defense CUI chain: SP 800-171 as pinned by contract, the CMMC program, the DFARS clauses

Makes demands of an organization, not a product

A chain that arrives only through a clause number, and that issues something different at every rung.

What it issues
Depends on the rung: a self-scored assessment, an annual affirmation, a third-party certificate, or a government assessment result.
What triggers it
A contracting officer inserting a clause, or a prime flowing it down. Nothing here arrives on its own.
Status, checked 2026-08-06
Program rule effective 2024-12-16; acquisition rule effective 2025-11-10; phases beyond the first suspended by policy on 2026-07-13, per secondary reporting.
The check you can run without trusting this page

Two of them. "Defense work has to move to Revision 3": a class deviation issued 2024-05-02 pins the safeguarding clause to Revision 2 and stands until rescinded, per secondary reporting, so the clause text alone gives the wrong revision. And "third-party certification becomes a condition of award in November 2026": Phase 2 and later milestones were suspended by policy on 2026-07-13, per secondary reporting, and neither rule was amended or repealed. Ask the contracting officer which level the solicitation requires, and check the rulemaking index.

This document's section in the reference table

CISA Known Exploited Vulnerabilities catalog, and BOD 26-04

Makes demands of an organization, not a product

A catalog that binds nobody privately, plus a directive that binds only the agencies it names.

What it issues
Nothing to a private organization. A directive binds only the agencies it names.
What triggers it
Being an agency a directive names, a contract flowing it down, or your own policy adopting the catalog.
Status, checked 2026-08-06
BOD 26-04, issued 2026-06-10, supersedes and revokes the 2021 and 2019 directives. The catalog itself is unchanged.
The check you can run without trusting this page

"Catalog inclusion means a fixed federal patch deadline." The directive setting flat due dates was revoked on 2026-06-10 and replaced by a risk model. The catalog is unchanged, and the revoked directive's own page is titled as revoked.

This document's section in the reference table

EPSS

Makes demands of an organization, not a product

A published probability per CVE, consumed by a policy rather than imposed by one.

What it issues
A daily probability and percentile per published CVE, for exploitation in the wild within thirty days.
What triggers it
A remediation policy that consumes it, or a risk model using exploitation likelihood as an input.
Status, checked 2026-08-06
Version 4 deployed 2025-03-17; a version 5 was announced 2026-05-13. Which model generates the published scores was not confirmed.
The check you can run without trusting this page

Read as a verdict rather than as data. Which model version is actually generating the published scores is not confirmed here -- read the comment line in the published data file, not a blog post.

This document's section in the reference table

NIST SP 800-122

Makes demands of an organization, not a product

Guidance on protecting personally identifiable information (PII), sitting to the side of the federal control chain.

What it issues
Nothing. Guidance.
What triggers it
No independent trigger. It sits beside the federal control chain, covering personally identifiable information (PII).
Status, checked 2026-08-06
Still Final. Its withdrawal exists only as intent inside an unfinished working draft.
The check you can run without trusting this page

"SP 800-122 was withdrawn." It is still Final, and the publication's own record page shows status and date.

This document's section in the reference table

NIST SP 800-161 Rev. 1 (upd 1)

Makes demands of an organization, not a product

Supply chain risk guidance structured as an overlay on the control catalog.

What it issues
Nothing. Guidance, structured as an overlay on the control catalog.
What triggers it
A federal contract flow-down, or a prime pushing supply chain terms down.
Status, checked 2026-08-06
Revision 1 published May 2022; update 1 issued 2024-11-01. No Revision 2 exists in any form, draft or final.
The check you can run without trusting this page

"Revision 2 is out." There is no Revision 2. The 2024-11-01 date people cite is an update to Revision 1, and the publication's own record page shows status and date.

This document's section in the reference table

NIST SP 800-53 Rev. 5 (Release 5.2.0), with SP 800-53B and FIPS 199

Makes demands of an organization, not a product

The federal control catalog, its baselines, and the categorization that selects them.

What it issues
Nothing. A baseline is selected and an authorizing official decides. NIST certifies nobody.
What triggers it
A federal contract, a program requirement, or a customer questionnaire mapping its control set onto you.
Status, checked 2026-08-06
Release 5.2.0 issued 2025-08-27 and added three controls; the baselines were not changed. FIPS 199 unchanged since February 2004.
The check you can run without trusting this page

Questions arrive attached to the wrong link in the chain. The chain worth carrying: FIPS 199 categorizes, SP 800-60 Rev. 1 guides the categorizing, FIPS 200 sets a floor, SP 800-53B selects a baseline, SP 800-53 supplies the control text, and SP 800-53A assesses it. A release is also not a revision.

This document's section in the reference table

OWASP SAMM v2.0

Makes demands of an organization, not a product

A self-assessed maturity model with a community comparison benchmark.

What it issues
Nothing. A self-assessed score from 0 to 3 per practice, plus a community Benchmark for comparison.
What triggers it
Internal program work, board reporting, or a customer asking how mature your program is.
Status, checked 2026-08-06
Released February 2020 and still current on the check date. The Benchmark was first published June 2024.
The check you can run without trusting this page

A self-assessed score is offered as though it were an independent finding.

This document's section in the reference table

CVE Program

Input you use, not a rule you meet

Identifiers and records that every dependency policy and every scanner is written in.

What it issues
Identifiers and records. Not severity, not exploitability, not priority.
What triggers it
A dependency policy, a customer contract or support agreement, or your own vulnerability management -- covering both what you consume and what you ship. The program demands nothing itself: what obliges anyone to act on a published identifier is the policy or the clause that quotes it.
Status, checked 2026-08-06
Operating. The 2025 contract lapse was averted by an extension, and the program board was told on 2026-01-21 there is no funding cliff in March. Replacement terms are not public.
The check you can run without trusting this page

No published vulnerability identifiers is not a security property: it can equally mean nobody is looking, or that there is no route to publish one.

This document's section in the reference table

CWE 4.20

Input you use, not a rule you meet

An identifier space for classes of mistake. You cannot conform to it.

What it issues
An identifier for a class of mistake. Not a severity and not a priority.
What triggers it
Tool output, vulnerability records that map to it, and contracts asking for findings with mappings.
Status, checked 2026-08-06
Version 4.20 released 2026-04-30, on a continuing versioned release cadence.
The check you can run without trusting this page

A weakness identifier is not a severity: it says what kind of mistake a finding is, not whether it matters where you run.

This document's section in the reference table

ISO/IEC 25010:2023

Input you use, not a rule you meet

A vocabulary of quality characteristics, stating no requirement a product could meet or fail.

What it issues
A vocabulary of quality characteristics. It states no requirement a product could meet or fail.
What triggers it
Requirements documents and procurement specifications that need both parties to mean the same thing.
Status, checked 2026-08-06
Second edition published November 2023, cancelling and replacing the 2011 edition. Usability and portability no longer exist as top-level names.
The check you can run without trusting this page

"Usability is a characteristic." It was replaced in the 2023 edition, so a requirements document written against the 2011 names no longer resolves.

This document's section in the reference table

SBOM formats: SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424, 2nd edition)

Input you use, not a rule you meet

Two machine-readable document formats. No conformance mark exists for either.

What it issues
A machine-readable document a parser accepts. No conformance mark exists for either.
What triggers it
A customer or a regime asking for an SBOM in a commonly used machine-readable format.
Status, checked 2026-08-06
ISO/IEC 5962:2021 describes SPDX 2.2.1, which current tooling has moved past; SPDX 3.0 sat at draft stage on the check date. ECMA-424 2nd edition was adopted December 2025 and defines CycloneDX v1.7.
The check you can run without trusting this page

"Prefer SPDX because it is the ISO standard." A format's standards-body lineage is not a compliance grade, and the widely quoted ISO number attaches to a 2021-era version rather than to what current tooling emits. Choosing on lineage answers a question nobody in the transaction asked.

This document's section in the reference table

in-toto attestations and Sigstore signing

Makes demands of a software producer

The attestation format and the signing service that provenance requirements are usually written on top of.

What it issues
Sigstore issues identity-bound short-lived certificates plus a public transparency log entry. These evidence who signed and when, and nothing about what was signed. Its public instances are community-operated with no service level.
What triggers it
A provenance or signing requirement from a customer or a package ecosystem.
Status, checked 2026-08-06
No separate status is recorded here beyond the facts in this row.
The check you can run without trusting this page

Offered as a choice against build provenance. Provenance is written as an in-toto attestation, so the two are layered rather than rival options; a requirements document offering a choice between them was written by someone who had not read either.

This document's section in the reference table

Governs the examiner, not you

These change what an audit looks like and impose nothing on you. Reading them as requirements on yourself manufactures controls nothing ever asked for, which is why the label comes before the names.

ISO/IEC 27006-1:2024

Makes demands of an assessor

Governs the certification bodies that audit management systems, and the terms of their accreditation.

What it issues
Nothing to the audited organization. It governs the auditor.
What triggers it
It affects you through changed audit conduct: refined remote-audit rules and a revised audit-time calculation.
Status, checked 2026-08-06
Published 2024, replacing the 2015 edition. One accreditation body required use for all clients by 2026-03-31; other bodies may differ. Ask your own certification body which date applies to it.
The check you can run without trusting this page

Read as a requirement on yourself, which manufactures controls the standard never asked for. An unexplained change in audit shape or duration usually starts here rather than in your auditor's temperament.

This document's section in the reference table

NIST SP 800-171A Rev. 3 and SP 800-172A Rev. 3

Makes demands of an assessor

The procedures for a CUI assessment, whether run by a third party or by the government.

What it issues
Nothing to the audited organization. A CUI assessment run to these procedures carries findings only, and there is no pass mark.
What triggers it
An assessment somebody else scopes and runs.
Status, checked 2026-08-06
800-171A Rev. 3 final 2024-05-14; 800-172A Rev. 3 final 2026-05-13. The defense program rule still names the June 2018 and March 2022 versions.
The check you can run without trusting this page

The newest published procedure is assumed to be the one being assessed against. The program rule still names earlier versions.

This document's section in the reference table

NIST SP 800-53A Rev. 5 (Release 5.2.0)

Makes demands of an assessor

The assessment procedures for the federal control catalog. A method manual for the examiner.

What it issues
Nothing to the audited organization.
What triggers it
It affects you as the source of the questions an assessor asks about a deployed instance.
Status, checked 2026-08-06
Release 5.2.0 issued 2025-08-27, adding assessment procedures for three controls.
The check you can run without trusting this page

"Makes demands of an assessor" does not mean "what an auditor will ask you for". It tells someone how to conduct an examination. Building to it produces controls nothing ever required.

This document's section in the reference table

Not on this map

Jurisdictions outside the US and the EU. US state privacy laws. The rest of the ISO/IEC 27000 series and the AI management-system standards. The NIST Cybersecurity Framework and the NIST AI Risk Management Framework. Common Criteria and product evaluation schemes. Proprietary assurance schemes and regional cloud programs. Safety-oriented standards for industrial and vehicle software. Sector regimes beyond the several named here as a set. Also absent: the enforcement and liability exposure that attaches to a signature or a representation, which is a question for counsel and not for this page.

If what applies to your situation sits in one of these, this page will tell you nothing about it, and you should not read its silence as coverage.

The longer version, further down this page

How these actually arrive

At least five routes. The route decides the owner far more reliably than the subject does, which is why this is the part that decides where budget lands.

Route in What it looks like on the day What actually governs Who owns the response internally
A direct binding on a producer A market-access rule you satisfy before you ship, with no customer asking The regulation and the conformity route it sets Engineering and release, not the compliance function
A clause in one specific contract, or a flow-down from a prime A clause number in a solicitation or an award The clause text, plus any deviation that modifies it. Not the publication it cites Contracts, with security supplying the evidence
A supplier-risk clause inside somebody else's regime -- the questionnaire A spreadsheet quoting identifiers drawn from several unrelated documents Their obligation, not yours. It never binds you; it obliges them to ask Security with sales, and it is the largest recurring cost in this table
A procurement or payment-chain agreement A program status or a validation requirement as a condition of the deal The program's or the counterparty's own rules, which may not be the standard author's The program owner, usually outside security
Your own risk decision Nobody asked. You adopted it Your own written scope, and nothing else Whoever proposed it, and that should be written down
Why every identifier here carries a version

What binds you is a clause, and a clause pins a dated version. "Use the current publication" is frequently the wrong instruction: a regulation citing a publication by date keeps citing it after the publisher supersedes it, which is how a rule stays stable rather than an error in it. That is why no identifier here appears without its version, revision, edition or release.

Every status shown here was checked on the date printed beside it. This is a snapshot, not a maintained register: several of these facts changed within the twelve months before that date and some will have changed since. Re-check anything you intend to rely on at the publisher's own listing, the program's own definitions page, the clause and its deviations, or the data file's own header.

If this is your situation

At least twelve situations. Matching no row here is not evidence that nothing applies to you – see what this page did not assess.

Your situation What applies to you, and how it arrives Read next
You sell software, not a hosted service, to a US federal agency Since 2026-01-23 there is no government-wide attestation mandate. What applies to you is whatever an individual agency writes into a contract The producer rows, and why every status carries a date
You sell a hosted service to a US federal agency A government program certification for the offering, as a condition of the sale. It arrives as a procurement rule The program regimes
You sell to a US state, local, tribal or education buyer A separate program with its own statuses and tiers, arriving as a procurement requirement that varies by jurisdiction The program regimes
You place a product with digital elements on the EU market A regulation that binds producers directly, with no customer asking – the only such item mapped here. Its reporting obligations apply from 2026-09-11, ahead of the rest of it. Whether what you place is a product with digital elements in the regulation’s own sense is the thing to check, and this page cannot settle it How these actually arrive
A prime contractor flowed a security requirement down to you A clause, not a publication. Ask which contract and which clause number, and whether a deviation modifies it How these actually arrive
A commercial customer requires a certificate or an audit report before signing An instrument that does exist, unlike most of the reference. It is evidence about the ORGANIZATION and not about the software, and what it is worth turns on scope, accreditation, and which criteria were elected The organization layer is not the software layer
A customer questionnaire asks you for a certificate A questionnaire is not a regulator. Most items in the reference issue no certificate, so name what does exist: a scoped certificate for something else, a report, a self-attestation, provenance, or named control correspondences What each one issues
A contract clause names a ranking, such as free of OWASP Top 10 issues A clause with no completion condition. Convert it into a requirement set while the clause is being agreed, not when the assessment is due Rankings and awareness lists
You operate systems holding data covered by a sector regime A regulator’s rule on the organization, not on a product. It arrives at a supplier as contract text rather than as regulation The sector regimes
You are in the payment card chain An agreement with an acquirer or a brand. The body that writes the standard is not the body that sets your validation requirement The program regimes
You supply software to an organization in scope of a regime, and you are not A supplier-risk questionnaire generated by their obligation. The contract text governs what you owe, not the underlying regime How these actually arrive
Your developers build with AI coding assistants Nothing mapped in the reference governs it. Three documents are routinely offered as though they do, and each is about something else Where an AI coding assistant sits

Where an AI coding assistant sits in all this

Nothing mapped in the reference currently governs a developer using an AI coding assistant. That is a finding about the landscape, stated as an absence rather than as a gap somebody has filled. It is the one situation above whose answer will not fit in a table cell, because the answer is a correction to three specific documents rather than a list.

  • The SSDF community profile for AI models addresses producing models: data sourcing, training, fine-tuning, evaluation. Its one sentence on the subject says the practices do not distinguish AI-generated source code from human-written code, which is a scoping exclusion rather than guidance.
  • The LLM application ranking addresses securing an application that calls a language model at run time. That is a different subject from governing what an AI coding assistant writes for you, and the two are conflated constantly.
  • The NIST control overlays for securing AI systems are in development. Nothing can be aligned with them until a draft exists, and the reference row carries the status as at the date it was checked.

All three carry their full rows in the reference. No claim is made here that anything published on this site fills that gap: the control set this site does publish for AI-assisted work is AI-assisted development, and it claims correspondence with nothing.


What this page did not assess

The routing above covers at least the items in the reference. That is not a complete map of the security standards landscape and does not claim to be. The selector carries this same list as a permanent card, in every state including a result with nothing in it, because a short result is exactly where a reader misreads silence as clearance.

What is absent entirely. Jurisdictions outside the US and the EU. US state privacy laws. The rest of the ISO/IEC 27000 series and the AI management-system standards. The NIST Cybersecurity Framework and the NIST AI Risk Management Framework. Common Criteria and product evaluation schemes. Proprietary assurance schemes and regional cloud programs. Safety-oriented standards for industrial and vehicle software. Sector regimes beyond the several named here as a set. Also absent: the enforcement and liability exposure that attaches to a signature or a representation, which is a question for counsel and not for this page. If what applies to your situation sits in one of these, this page will tell you nothing about it, and you should not read its silence as coverage.

What is covered but not primary-verified is listed row by row in the reference, each with the check to run instead of trusting the page. One limit covers a whole class and is stated once rather than repeated per row: several US regulator and agency sites refused automated requests on the check date, so claims sourced to them were read through search results rather than end to end.

Questions this page structurally does not answer. Whether any of this binds your organization: a clause number decides that, not a web page, and a document that applies to your situation may still not oblige you. Whether you must comply with anything: no legal advice is given here. Which tool, scanner, format or assessor to use: none is named. Whether anything published on this site conforms to, aligns with or partially satisfies anything named here: it does not, and no such claim is made. And how much any of it costs, in money, effort or time: not assessed.


If you need Read
One row per document, with statuses, and the reasoning behind the cuts The standards reference
Whether your teams already do this, rather than which standards apply to you The CISO summary
The control set for AI-assisted work AI-assisted development
How much of the code a human must read Human review of code
The process a build must satisfy, and who owns which control Secure development
Trusting code you did not write, and controlling what you publish Dependency integrity
Judging code, whoever wrote it Code quality
Running an assessment against a standard with several hundred requirements Use OWASP ASVS 5.0
Saying which kind of claim you are making CI and standards
All of it, and how to adopt Overview

The dated facts in the routing table were checked on 2026-08-06, the same date the reference carries against every status. This is a snapshot, not a maintained register: several of those facts changed within the twelve months before that date, and some will have changed since. Re-check anything you intend to rely on at the four places named in Sources before quoting it.

MIT licensed. Adapt this, put your own name on it, and delete anything you cannot stand behind. Re-date it when you do: a status claim inherits the date it was checked, not the date it was copied.