Security Requirement Catalog Taxonomy

A team adds a requirement for customer export jobs: every download must be authorized against the requesting tenant. One reviewer files it under API security because an endpoint enforces it. Another chooses authorization because the decision is about object access. A third chooses data protection because exports contain sensitive records. All three readings are defensible. If the team copies the requirement into three domains, however, it has created three candidates for amendment, exception, and retirement. They will eventually disagree.

A catalog taxonomy should give one requirement one durable home while preserving every useful path to it. Its prefixes are addresses, not a model of the whole control. Ownership, applicability, evidence, threats, and related controls belong in the record and can cross every domain boundary.

Give each requirement one address

Use a three-part identifier:

PREFIX-FAMILY-SEQUENCE

The prefix names the primary security decision. The family groups nearby requirements without changing their domain. The sequence distinguishes one requirement from another; it does not express priority, maturity, or document order.

The export control from the opening belongs under AUTHZ because its decisive question is what an authenticated actor may do to a tenant-scoped object. AUTHZ-EXPORT-004 remains its canonical ID even if the API is replaced by an asynchronous job, the data classification changes, or another team takes ownership. Its record links to API exposure, protected data, export monitoring, and incident response. Those links provide alternate routes without creating alternate copies.

Keep an ID stable after issue. Improve the wording, applicability, guidance, and verification in place. When the security decision itself changes incompatibly, retire the old requirement as superseded and issue a new ID. Never silently reuse an old ID for a different obligation: reviews, exceptions, incidents, and evidence may still refer to its earlier meaning.

Choose the domain by the controlled decision

Ask what decision would remain if the current implementation disappeared. That question is more durable than asking which component contains the code or which team owns the service today.

• GOV — who owns the risk, has decision authority, or may approve an exception.
• INV — what asset, dependency, service, owner, exposure, telemetry source, or criticality must be known.
• DATA — how data is classified, retained, deleted, exported, or redacted.
• TM — which attacker path, abuse case, or trust boundary must be modeled and traced.
• AUTHN — how a human, administrator, workload, service, or device proves identity and maintains a session.
• AUTHZ — which subject may perform which action on which resource, including tenant isolation and delegated access.
• API — how callable service behavior is exposed, bounded, validated, and protected from abuse.
• WEB — how browser and client-side paths handle scripting, request forgery, framing, uploads, and local storage.
• CRYPTO — how algorithms, keys, and cryptographic operations are selected and managed through their lifecycle.
• SECRETS — how credentials are stored, delivered, rotated, detected when leaked, and revoked.
• NET — which ingress, egress, segmentation, administration, and transport paths are permitted.
• CLOUD — which account boundaries, identity guardrails, landing-zone controls, and cloud audit sources apply.
• K8S — which cluster, workload, admission, network-policy, RBAC, image, and runtime controls apply.
• CICD — how protected source becomes a trusted, attributable, and safely released artifact.
• SUPPLY — which external package, registry, dependency, and build input may be trusted and how exposure is found.
• IAC — how infrastructure changes are reviewed, checked by policy, promoted, and reconciled against drift.
• AI — how model inputs, datasets, retrieval, tools, outputs, and evaluations are bounded against abuse.
• LOG — which events are recorded and how audit data is attributed, protected, retained, and made usable.
• VM — how a finding is prioritized, assigned, remediated, excepted, verified, and closed.
• ACCESS — how production privileges are granted, elevated, observed, reviewed, and revoked.
• OPS — how live-system hardening, configuration, change, and routine control ownership are maintained.
• DET — which threat behavior is detected, tested, routed, tuned, and retired.
• IR — which authority, escalation, communication, containment, and evidence-handling rules apply during an incident.
• REC — how backups, restoration, eradication validation, and recovery readiness are established.

These domains are navigation anchors, not lifecycle gates. A CLOUD requirement may shape architecture, implementation, operations, and response. A DET requirement may require LOG telemetry and an IR playbook. Place the requirement where its controlling decision is clearest, then make the dependencies explicit.

Resolve ambiguous placements without duplication

Some requirements will resist the first prefix. Write down the obligation in the normative form from Appendix A, then remove the product name and implementation nouns mentally. What remains usually exposes the decision.

Consider a production workload that retrieves a database credential through workload identity. If the obligation is that the workload must obtain a short-lived secret from the approved manager, use SECRETS. If it constrains which workload identity may access which secret, use AUTHZ. If it defines how the workload proves its identity, use AUTHN. These controls may be related, but they can fail independently and deserve separate records.

When two prefixes still seem equally plausible:

1. Choose the domain that owns the pass-or-fail security property.
2. Record every secondary domain as a searchable relation or tag.
3. Link related controls rather than repeating their text.
4. Ask an engineer unfamiliar with the catalog to find the requirement from the system or threat that would lead them to it.
5. Add an alias or navigation entry if discovery fails; do not mint a second canonical control.

This is also why organization names make poor prefixes. Teams split, merge, and rename. A stable security decision can outlive several ownership changes.

Preserve more than a title and sentence

The normative sentence is the catalog’s decision surface. Its record must also carry enough context to apply, challenge, operate, and retire that decision:

id:
title:
status:
domain:
family:
applicability:
assurance_level:
requirement:
rationale:
implementation_guidance:
verification:
evidence:
common_bypasses:
related_threats:
related_controls:
related_playbooks:
secondary_domains:
framework_mapping:
implementation_owner_role:
evidence_owner_role:
exception_route:
review_triggers:
supersedes:
superseded_by:

Keep ownership separate from taxonomy. The team implementing a requirement and the role accountable for its evidence may differ, and neither should determine the prefix. Prefer review triggers—such as a trust-boundary change, new exposure, incident, failed test, or platform retirement—to a ceremonial cadence. Add a cadence only where time itself creates meaningful risk.

The catalog should be machine-searchable even when its source is Markdown. Constrained values for status, domain, assurance level, and relationships make it possible to find applicable controls, unresolved exceptions, missing verification, and superseded references without flattening the rationale into cells.

A complete control in its catalog

The export requirement can now travel as one record:

id: AUTHZ-EXPORT-004
title: Authorize tenant export jobs
status: active
domain: AUTHZ
family: EXPORT
applicability: tenant-scoped export endpoints and jobs, Level 2+
requirement: >
  The service MUST authorize every read, download, cancellation, and deletion
  of an export job on the server using the authenticated subject, action,
  export resource, and tenant context.
rationale: An authenticated user may otherwise act on another tenant's export job.
verification:
  - negative cross-user and cross-tenant tests for every governed action
  - review of each policy enforcement point
  - production authorization-denial event check
evidence:
  - test result attributed to the release and service
  - policy review record
  - retained denial events with tenant-safe fields
common_bypasses:
  - authorization performed only when the job is created
  - user-interface visibility treated as access control
  - worker reads the export without preserving tenant context
secondary_domains: [API, DATA, LOG]
related_controls: [DATA-EXPORT-002, LOG-AUTHZ-003]
related_playbooks: [IR-DATA-ACCESS]
implementation_owner_role: export service owner
evidence_owner_role: release reviewer
review_triggers:
  - new export action or delivery path
  - authorization model or tenant-boundary change
  - cross-tenant access finding

The record does not turn three domains into one control. DATA-EXPORT-002 can govern export classification, retention, and deletion; LOG-AUTHZ-003 can govern denial-event content and protection. Each has its own failure condition. The links show that a safe export depends on all three.

Review the catalog as a system

A tidy list can still fail its users. Review the catalog for behavior rather than visual completeness:

• Search for duplicate obligations expressed under different prefixes. Decide which ID is canonical, migrate references, and supersede the duplicate explicitly.
• Sample mandatory controls and confirm that each has applicable systems, an implementation owner, a verification method capable of failure, attributable evidence, and an exception route.
• Follow cross-domain relations in both directions. A detection should expose the telemetry and response playbook it depends on; the telemetry and playbook should reveal the detection that consumes them.
• Inspect open exceptions and retired controls for dangling references. Supersession should not leave a release profile pointing at a requirement whose meaning has vanished.
• Treat framework mappings as alternate indexes for assurance work. They do not prove that the engineering obligation is satisfied.

Then test discovery. Give five engineers a system change or threat scenario and ask each to find the controls that govern it without knowing the security team’s organization. Record the searches that failed. A useful taxonomy grows aliases, relations, and search vocabulary from those failures while keeping the canonical IDs stable.

Field Reference

When placing a requirement:

Choose the prefix for the security decision that must pass or fail.
Keep one canonical ID.
Link every secondary domain, threat, control, playbook, owner, and evidence path.

When changing a requirement:

Preserve the ID while clarifying the same obligation.
Issue a new ID when the security decision changes incompatibly,
and retain the supersession trail.