CSSLP · Secure Software Requirements

Security requirement

A documented, approved, and verifiable statement of a security property, behavior, constraint, or outcome that the software or its supporting environment must satisfy.

Example: Replace the vague statement with a requirement that identifies the subject, protected object, triggering condition, required behavior, and verification criterion.

Counterexample: Approve “The application shall be secure” as a complete requirement without defining observable behavior or a pass/fail test. | Replace the sentence with “Use AES-256 and MFA” without stating protected objects, conditions, or expected behavior. | Accept the statement because penetration testing will determine whether the application is secure, and the test team would still have no objective pass/fail basis.

Requirement sources

Security requirements are derived from business objectives, asset and data classification, risk assessments, threat and abuse analysis, laws and regulations, contracts, organizational policy, architecture constraints, prior incidents, and stakeholder needs.

Example: Derive candidate requirements from the business objective, assets, data classification, risks, threats, obligations, policies, incidents, and stakeholder needs before choosing a solution.

Counterexample: Choose a cipher immediately from the phrase “protect data” and skip the business, asset, risk, obligation, and context analysis. | Derive requirements only from the architect’s preferred technology and omit contracts, incidents, policies, and stakeholder needs. | Write one generic protection requirement and leave the conflicting source obligations unmapped, and the baseline would still confuse the required outcome with the chosen implementation.

Requirement versus control

A requirement states the outcome that must be achieved.

Example: State the required confidentiality outcome, scope, conditions, and verification first, and treat AES-256 as a later control or mandated design constraint.

Counterexample: Mandate AES-256 immediately and use the algorithm name as the confidentiality requirement, and separate owners could not make independent acceptance decisions. | Document only the selected control and skip the protected data, threat conditions, and acceptance test. | Let implementation details determine the requirement after development is complete, and the source and acceptance links would remain incomplete.

Requirement quality attributes

High-quality requirements are correct, necessary, complete, consistent, feasible, unambiguous, prioritized, traceable, modifiable, and verifiable.

Example: Resolve the undefined terms and confirm the requirement is necessary, complete, consistent, feasible, prioritized, traceable, modifiable, and verifiable.

Counterexample: Keep terms such as strong, adequate, reasonable, and where possible without a defined benchmark. | Add a deadline but leave the requirement inconsistent with another approved obligation and impossible to verify. | Treat traceability and prioritization as project-management details rather than requirement quality attributes, and separate owners could not make independent acceptance decisions.

Atomicity

An atomic requirement expresses one independently verifiable obligation.

Example: Split the statement into separate requirements wherever owners, controls, tests, or acceptance decisions differ.

Counterexample: Keep authentication, encryption, logging, availability, and retention in one requirement with one combined pass/fail result. | Keep the combined statement and mark it passed when any one of the five obligations succeeds. | Split the statement by sentence length rather than by independent owner, control, test, and acceptance decision.

Prioritization

Requirements are prioritized using legal mandate, risk, asset criticality, business impact, dependencies, release criteria, cost, and feasibility.

Example: Keep the mandatory obligation in scope, sequence prerequisite work explicitly, and use risk, impact, dependency, and feasibility to order implementation.

Counterexample: Implement the item labeled high priority before its prerequisite controls and mandatory dependencies are ready. | Drop the mandatory notification obligation because implementation is inconvenient this release, and separate owners could not make independent acceptance decisions. | Rank every item only by implementation cost and ignore legal mandate, business impact, and dependency.

Acceptance criteria

Acceptance criteria convert a requirement into observable pass/fail conditions.

Example: Add observable positive, negative, boundary, timing, evidence, and tolerance conditions that yield an unambiguous pass or fail.

Counterexample: Repeat the user story as its acceptance criteria without adding measurable positive, negative, boundary, timing, or evidence conditions. | Use “security review completed” as the acceptance result without identifying expected behavior or evidence. | Test only the successful administrator path and omit unauthorized, boundary, failure, and timing conditions.

Verification methods

Requirements may be verified by inspection, analysis, demonstration, testing, audit evidence, or a combination.

Example: Select verification methods suited to each property, using recovery exercises for continuity and positive and negative tests for authorization.

Counterexample: Use code coverage alone as proof that the recovery-time requirement has been validated, and separate owners could not make independent acceptance decisions. | Use document inspection for the recovery-time objective and skip an exercise or restoration demonstration. | Run one positive authorization test and omit denial and boundary cases, and the source and acceptance links would remain incomplete.

Functional security requirement

A functional security requirement defines a security behavior the system must perform, such as authenticating a user, enforcing authorization, generating an audit event, revoking a session, or obtaining consent.

Example: Write a functional requirement that the system require MFA before granting an interactive administrator session.

Counterexample: Classify the MFA behavior only as a non-functional quality because it relates to security. | Write that administrator sessions should use strong authentication where practical, and the baseline would still confuse the required outcome with the chosen implementation. | Specify only the maximum login latency and omit the required authentication behavior.

Non-functional security requirement

A non-functional requirement defines a security quality attribute, constraint, operating condition, service level, continuity objective, or deployment property.

Example: Treat tamper evidence, seven-year retention, and availability as mandatory non-functional constraints with measurable verification.

Counterexample: Treat the seven-year retention and tamper-evidence constraints as optional because they do not describe a user function. | Replace the measurable retention period with “retain records as long as needed.” | Write only that the system generates audit events and omit integrity, availability, and retention qualities.

Operational requirement

An operational requirement defines secure behavior and constraints during deployment and operation, such as logging, monitoring, administrative access, key rotation, backup, recovery, and secure failure.

Example: Specify required logging, monitoring, administrative access, key rotation, backup, recovery, and secure-failure outcomes, while leaving operational implementation to Domain 7.

Counterexample: Defer logging, monitoring, key rotation, backup, and secure-failure decisions until operations begins, and the baseline would still confuse the required outcome with the chosen implementation. | Write only that the service must be available and leave administrative access and recovery behavior undefined. | Specify the exact monitoring product and backup tool without stating the required operational outcomes.

Continuity requirement

A continuity requirement defines availability, resilience, recovery, backup, restoration, and business-continuity outcomes, often using RTO, RPO, maximum tolerable downtime, or service-degradation criteria.

Example: Specify a two-hour RTO and a fifteen-minute RPO, together with restoration evidence and any approved degraded-service criteria.

Counterexample: Reverse the values and set the RTO to fifteen minutes and the RPO to two hours. | State only that service should recover quickly and data loss should be minimal. | Use backup frequency as proof that the restoration-time objective will be met, and the baseline would still confuse the required outcome with the chosen implementation.

Deployment requirement

A deployment requirement constrains where, how, and under what security conditions software may be installed or released, including environment separation, approved configurations, secrets handling, and platform prerequisites.

Example: Require deployment only to approved environments and rejection of artifacts or configurations that fail signature and baseline validation.

Counterexample: Allow deployment to any environment if the artifact passed functional tests, and separate owners could not make independent acceptance decisions. | Validate the artifact signature but ignore the approved configuration and platform prerequisites, and the test team would still have no objective pass/fail basis. | Specify a particular deployment tool but omit environment separation, secret handling, and release conditions.

Business security requirement

A high-level statement connecting security to business value, mission, risk tolerance, contractual duty, or legal obligation.

Example: Refine the business risk statement into traceable system and software requirements with measurable acceptance criteria.

Counterexample: Treat the high-level business risk statement as a directly testable software requirement without refining it. | Replace the business risk statement with a named security product and no system-level behavior. | Keep the business statement unlinked to software requirements, acceptance criteria, and verification evidence.

Use case

A use case describes how an authorized actor interacts with the system to achieve a legitimate goal.

Example: Document the authorized actor, preconditions, normal and alternate flows, exceptions, postconditions, and security constraints, then model hostile manipulation separately.

Counterexample: Assume the normal account-update flow also covers malicious identifier changes and out-of-order workflow manipulation, and separate owners could not make independent acceptance decisions. | Add malicious parameter changes to the normal flow and treat them as authorized alternate behavior. | Document only the actor and happy path, omitting preconditions, exceptions, postconditions, and security constraints.

User story

An Agile expression of desired capability, commonly “As a [role], I want [capability], so that [value].” Security stories require explicit acceptance criteria and may also be represented as security constraints on business stories.

Example: Attach security acceptance criteria to affected business stories, add dedicated security stories where needed, and include cross-cutting controls in the definition of done.

Counterexample: Create one generic security story and leave the affected business stories without security acceptance criteria, and the baseline would still confuse the required outcome with the chosen implementation. | Put all security work in a separate backlog that product teams do not reference during business delivery. | Add a security label to each story but no acceptance criteria or definition-of-done condition, and the test team would still have no objective pass/fail basis.

Negative requirement

A requirement that states behavior the system must not permit.

Example: Require the trusted server or policy decision point to deny access to another customer’s record even when a user changes an identifier.

Counterexample: Rely on hiding the administrative button in the browser as the authorization requirement, and the source and acceptance links would remain incomplete. | Require the API to return an error only after it has retrieved and exposed the other customer’s record. | Write “users should not change identifiers” without defining trusted authorization enforcement and a negative test, and the baseline would still confuse the required outcome with the chosen implementation.

Security requirements elicitation techniques

Security requirements may be elicited through interviews, facilitated workshops or JAD sessions, questionnaires, observation, document analysis, brainstorming, prototypes, and structured expert techniques such as Delphi.

Example: Use interviews for depth, questionnaires for broad input, workshops for conflict resolution, observation for actual practice, document analysis for obligations, and Delphi for controlled expert convergence.

Counterexample: Treat stakeholder interviews and workshops as final validation and approval of every elicited statement, and separate owners could not make independent acceptance decisions. | Use a questionnaire alone for a sensitive conflict that requires legal, operations, and product negotiation, and the test team would still have no objective pass/fail basis. | Use an open workshop for confidential stakeholder concerns where private interviews are needed, and the source and acceptance links would remain incomplete.

SMART quality heuristic

SMART is a commonly used heuristic for making requirements Specific, Measurable, Achievable or Actionable, Relevant, and Time-bound.

Example: Use SMART to expose vagueness and missing timing or measurement, then also verify completeness, consistency, traceability, feasibility, legal sufficiency, and approval.

Counterexample: Approve the statement because it is SMART even though it conflicts with law and lacks source, consistency, traceability, and evidence. | Use SMART as the only quality checklist and omit atomicity, authority, consistency, and legal sufficiency, and the baseline would still confuse the required outcome with the chosen implementation. | Rewrite the requirement to be measurable but leave the wrong business objective and source in place.

Compliance requirement

A mandatory or adopted obligation derived from law, regulation, contract, industry program, certification scheme, policy, standard, or organizational governance.

Example: Determine the source’s authority and applicability, interpret the obligation, and translate it into traceable software requirements before importing controls.

Counterexample: Apply every named regulation to the product without determining whether the organization, activity, data, or jurisdiction is in scope. | Translate the external clause directly into a technology mandate without interpreting the required outcome. | Record the source name but omit the authoritative clause, owner, verification, evidence, and review date.

Regulatory authority

A governmental or delegated body that issues, interprets, supervises, or enforces requirements within its jurisdiction.

Example: Identify which statements are binding, which are guidance, the regulator’s jurisdiction and enforcement scope, and the required reporting and evidence.

Counterexample: Give advisory guidance the same force as a binding rule without checking the authority, wording, and applicability. | Treat every regulator publication as nonbinding guidance and ignore enforceable rules, and the mapping would still omit the governing source or justified exclusion. | Identify the regulator but omit jurisdiction, regulated activity, reporting duties, evidence, and enforcement scope, and applicability and authoritative interpretation would remain unresolved.

Legal requirement

An obligation arising from statutes, regulations, case law, contracts, licensing, intellectual property, records rules, breach notification, or other legally enforceable sources.

Example: Escalate the conflict to qualified legal and privacy counsel, then implement and trace the approved interpretation.

Counterexample: Let developers choose between deletion, retention, and litigation obligations without qualified legal or privacy interpretation. | Implement the most privacy-protective option immediately even if it violates a preservation order. | Ask security engineering to issue the legal interpretation because it will implement the control.

Industry-specific requirement

A requirement specific to sectors such as defense, healthcare, commercial services, finance, or payment-card processing.

Example: Treat PCI DSS as a contractually or programmatically mandatory industry requirement for the applicable scope, not automatically as a statute.

Counterexample: Describe PCI DSS as a statute that applies identically to every application in every jurisdiction. | Ignore PCI DSS because it is not itself a law, and applicability and authoritative interpretation would remain unresolved. | Apply every PCI requirement to systems outside the contractually defined payment scope without analysis, and legal and privacy decision authority would remain unclear.

Company-wide requirement

An internally mandated requirement such as approved development tools, cryptographic standards, identity standards, frameworks, protocols, coding rules, logging schemas, or vulnerability-remediation timelines.

Example: Implement the approved internal cryptography standard because it is mandatory within the organization, while recording its internal source and scope.

Counterexample: Ignore the approved company cryptography standard because no external regulator explicitly names it, and residual risk outside the compliance scope would remain unaddressed. | Treat the company standard as external law and cite a regulator that did not issue it. | Allow each product to choose a different protocol despite the approved organization-wide mandate, and the mapping would still omit the governing source or justified exclusion.

Applicability analysis

The process of determining whether a requirement applies based on jurisdiction, data type, business activity, customer, system boundary, deployment model, and contractual relationship.

Example: Document applicability and justified non-applicability for each jurisdiction, data type, activity, customer, system boundary, deployment model, and contract.

Counterexample: Copy the entire external control catalog into the backlog and treat every clause as applicable. | Document only the clauses deemed applicable and omit justified non-applicability decisions, and legal and privacy decision authority would remain unclear. | Use the customer’s headquarters as the sole scoping factor and ignore data, activity, deployment, and contract.

Compliance mapping

A mapping from authoritative clause to interpreted obligation, requirement ID, control, owner, verification method, evidence, and review date.

Example: Maintain many-to-many links from authoritative clauses to interpreted obligations, requirement IDs, controls, owners, verification, evidence, and review dates.

Counterexample: Force each authoritative clause to exactly one requirement and each requirement to exactly one clause. | Map each clause only to a control and omit the interpreted obligation, requirement, owner, test, and evidence. | Duplicate the same software requirement for every source clause rather than maintaining shared mappings.

Compliance evidence

Objective records demonstrating implementation and operation, such as test reports, configuration exports, logs, approvals, assessments, training records, and audit artifacts.

Example: Collect objective evidence for the applicable version and environment, such as test results, configuration records, logs, approvals, assessments, and training records.

Counterexample: Use the policy and architecture diagram as proof that the required control is implemented and operating. | Use an assessor’s interview statement instead of records from the applicable version and environment, and residual risk outside the compliance scope would remain unaddressed. | Collect logs and test reports but omit their link to the governing requirement and review decision.

Compliance versus security

Compliance demonstrates satisfaction of defined obligations; security manages the broader risk landscape.

Example: Keep the certification evidence but separately assess and treat residual risks that fall outside its defined scope or controls.

Counterexample: Treat the certification as proof that the application has no material vulnerabilities or residual risk. | Stop risk analysis after the audit passes and close all findings outside the compliance scope. | Reject the certification entirely because it does not prove the absence of every vulnerability, and the mapping would still omit the governing source or justified exclusion.

Conflicting obligations

Requirements may conflict, such as deletion rights versus legal retention, monitoring versus employee privacy, or localization versus centralized operations.

Example: Document the conflict, obtain legal and privacy decisions, define the controlling conditions and exceptions, and trace the approved requirements and evidence.

Counterexample: Let a developer silently choose which obligation prevails and leave the exception undocumented, and residual risk outside the compliance scope would remain unaddressed. | Apply deletion everywhere and ignore the preservation order and fraud-investigation need, and the audit record would not prove the obligation operated in the applicable scope. | Retain everything indefinitely and treat that as resolution of the conflict, and the mapping would still omit the governing source or justified exclusion.

Data classification

The assignment of a protection category based on sensitivity, value, legal obligations, and the impact of unauthorized disclosure, alteration, loss, or unavailability.

Example: Classify the data using confidentiality, integrity, availability, privacy, safety, mission, financial, and reputational impact, then derive lifecycle handling rules.

Counterexample: Classify the data only by confidentiality and ignore integrity, availability, privacy, safety, mission, and financial impact. | Use one label based on business value but define no lifecycle handling requirements, and copies outside the primary platform would remain uncontrolled. | Allow each application to interpret the category differently without common impact criteria, and the decision would confuse technical custody with business ownership.

Data owner

The business role accountable for classification, acceptable use, access criteria, retention, and protection decisions for a data set.

Example: Have the accountable business data owner decide classification, acceptable use, access criteria, retention, and protection requirements.

Counterexample: Let the database administrator set the classification because the administrator has custody of the records. | Ask the security tool to infer classification and accept the result without business-owner approval. | Limit the owner’s decision to confidentiality and leave integrity, availability, access, and retention to ad hoc practice.

Data custodian

The operational or technical role that implements and maintains controls according to the data owner’s decisions.

Example: Have the custodian implement and operate the approved storage, backup, monitoring, access, and disposal controls without changing the owner’s business decisions.

Counterexample: Allow the custodian to lower the classification when approved controls are inconvenient to operate, and copies outside the primary platform would remain uncontrolled. | Treat technical possession of the database as ownership of the data and its acceptable use, and the decision would confuse technical custody with business ownership. | Ask the business owner to configure backups and monitoring instead of defining the required outcomes, and the rule would ignore a material integrity, availability, or aggregation impact.

Data dictionary

A controlled catalog of data elements, definitions, formats, sources, owners, classifications, valid values, relationships, integrity rules, retention, and privacy attributes.

Example: Extend the schema into a controlled data dictionary with definitions, sources, owners, classifications, valid values, relationships, integrity rules, retention, and privacy attributes.

Counterexample: Treat the database schema as a complete data dictionary even though business definitions, owners, classifications, and lifecycle attributes are missing. | Add owner names to the schema but omit definitions, classifications, valid values, relationships, and retention, and lifecycle handling would no longer follow the owner’s classification decision. | Let each consuming team maintain its own uncontrolled definitions for the same data elements, and copies outside the primary platform would remain uncontrolled.

Data labeling

The visible or machine-readable marking of data with its classification or handling attributes, such as document banners, metadata, database tags, or DLP labels.

Example: Preserve the classification and reapply visible or machine-readable labels and handling metadata after copying or format changes.

Counterexample: Declare the copied document public because its visible banner disappeared, and the decision would confuse technical custody with business ownership. | Use a label as the classification decision without an accountable owner or impact assessment. | Apply labels only to documents and omit database, metadata, DLP, and machine-readable uses.

Sensitivity and impact

Sensitivity reflects the need for protection; impact evaluates consequences to confidentiality, integrity, availability, privacy, safety, mission, finance, or reputation.

Example: Apply strong integrity and availability requirements to the public feed despite its low confidentiality sensitivity.

Counterexample: Apply no protection to the public feed because confidentiality is low. | Classify the feed as highly confidential and restrict all public access instead of addressing integrity. | Protect the feed’s availability but leave unauthorized modification and provenance undetected.

Structured data

Data organized under a defined schema, such as relational tables and fixed-format transactions.

Example: Define controls at the appropriate database, table, row, column, or field level according to classification and use.

Counterexample: Apply one classification to the entire database and ignore row- and field-level differences. | Export the table to a spreadsheet and assume the database controls continue to apply. | Use column encryption as the only requirement and omit row access, integrity, retention, and audit rules.

Unstructured data

Data without a fixed relational schema, such as documents, email, images, audio, chat, and source-code comments.

Example: Require classification-aware labeling, discovery, access, sharing, retention, and leakage controls across documents, email, images, chat, and code comments.

Counterexample: Treat documents and chat as low risk because they do not follow a relational schema. | Rely on users to preserve labels manually whenever files are copied or shared. | Scan email only and exclude images, audio, code comments, and collaboration repositories, and the rule would ignore a material integrity, availability, or aggregation impact.

Semi-structured data

Data with tags or flexible structure, such as JSON, XML, and many event formats.

Example: Treat the JSON records as semi-structured and define requirements for their tags, fields, validation, classification, and handling.

Counterexample: Classify the JSON events as fully unstructured and omit field and tag validation. | Treat every tagged record as structured enough to inherit database controls automatically, and lifecycle handling would no longer follow the owner’s classification decision. | Ignore schema evolution and allow new fields to bypass classification and handling rules.

Data lifecycle

The stages through which data passes.

Example: Cover generation or collection, classification, use, storage, transmission, sharing, retention, archive, backup, restoration, and disposal while preserving the official lifecycle examples.

Counterexample: Present collection, use, transmission, sharing, archive, backup, and restoration as the exact official ISC2 lifecycle list. | Limit lifecycle requirements to generation, storage, retention, and disposal and omit practical transmission and restoration conditions. | Use a different classification at every lifecycle stage without an approved transition rule, and the data category could not be applied consistently across formats and states.

Generation and collection

Requirements governing how data is created or acquired, including source validation, minimization, provenance, classification, and consent where applicable.

Example: Require source validation, provenance, minimization, classification, and applicable consent before collecting the device and location data.

Counterexample: Accept the device and location data because the mobile app already receives it, and classify it later. | Collect all available telemetry first and decide whether it is necessary after the analytics model is built. | Use one consent checkbox but omit source validation, provenance, minimization, and classification.

Storage

Requirements governing approved locations, encryption, access, segregation, backup, integrity, availability, and jurisdiction.

Example: Specify approved storage locations, access, segregation, encryption outcome, backup, integrity, availability, and jurisdiction for the restricted data.

Counterexample: Allow storage in any region as long as the provider advertises encryption, and the rule would ignore a material integrity, availability, or aggregation impact. | Define only backup frequency and omit approved locations, segregation, jurisdiction, and restoration integrity. | Let each application team choose its own storage and access rules.

Retention

Requirements defining what is retained, why, where, for how long, under whose authority, and how legal holds affect deletion.

Example: Define what is retained, why, where, for how long or until which trigger, under whose authority, and how legal holds suspend deletion.

Counterexample: Retain the records indefinitely because future legal or analytics needs are possible, and copies outside the primary platform would remain uncontrolled. | Delete records on a fixed date even when a valid legal hold applies, and the decision would confuse technical custody with business ownership. | Let the storage administrator choose retention duration based on available capacity, and the rule would ignore a material integrity, availability, or aggregation impact.

Disposal

Requirements defining secure deletion, media sanitization, destruction, downstream deletion, evidence of disposal, and treatment of backups.

Example: Require deletion or sanitization of primary, backup, replica, downstream, and media copies, with accountable approval and disposal evidence.

Counterexample: Delete only the primary database and treat the disposal requirement as complete, and the data category could not be applied consistently across formats and states. | Destroy media immediately without checking retention authority, legal holds, or downstream copies, and lifecycle handling would no longer follow the owner’s classification decision. | Rely on a vendor’s verbal assurance that backups and replicas will eventually expire.

Data handling

Rules that govern access, viewing, printing, copying, transmitting, exporting, sharing, logging, testing, storage media, and destruction based on classification.

Example: Define classification-based rules for viewing, printing, copying, transmitting, exporting, sharing, logging, test use, media, and destruction.

Counterexample: Permit printing and exporting because the user already has screen access, and the decision would confuse technical custody with business ownership. | Allow restricted production data in test environments after removing only direct names. | Use the same handling rules for public, internal, confidential, and restricted data.

Personally identifiable information (PII)

Information that directly identifies, indirectly identifies, or can reasonably be linked to an individual, depending on jurisdiction and context.

Example: Treat the combined fields as PII when they directly or indirectly identify or can reasonably be linked to an individual in context.

Counterexample: Remove PII requirements because the identifying fields are encrypted, and lifecycle handling would no longer follow the owner’s classification decision. | Look only for names and government identifiers and ignore combinations that reasonably link to a person. | Classify the data as non-PII because the organization does not intend to identify individuals, and the decision would confuse technical custody with business ownership.

Publicly available information

Information lawfully available to the public.

Example: Preserve authenticity, integrity, availability, licensing, provenance, and aggregation-risk controls for the public data.

Counterexample: Publish and combine public data without assessing whether aggregation can reveal sensitive facts. | Apply confidentiality controls but omit authenticity and integrity. | Assume lawful public availability also authorizes every reuse, aggregation, and republication.

Aggregation and inference risk

Individually low-sensitivity elements may become sensitive when combined, correlated, or analyzed.

Example: Assess and classify the combined data set, including correlation, inference, and external-data linkage, rather than rating each field alone.

Counterexample: Classify every field independently and ignore the sensitivity created by correlation and inference, and copies outside the primary platform would remain uncontrolled. | Assess the aggregate only for direct identifiers and ignore sensitive predictions and group inference. | Keep the lowest field classification for the combined data set because no individual element is restricted.

Data states: at rest, in transit, and in use

Protection requirements should identify the state in which data is exposed.

Example: State protection outcomes separately for data at rest, in transit, and in use, then let architecture select the appropriate mechanisms.

Counterexample: Mandate one technology for every data state without an authoritative requirement or architecture analysis, and the data category could not be applied consistently across formats and states. | Define protection only for storage and network transfer and omit decrypted processing and memory exposure. | Use encryption as the complete requirement for all three states and omit integrity, access, isolation, availability, and monitoring.

Tradeoffs: Domain 3 defines the required protection outcome for each state. Domain 4 selects the architecture, protocol, cryptographic mechanism, trusted execution design, or confidential-computing approach.

Privacy requirement

A requirement governing whether and how information about individuals is collected, used, disclosed, retained, transferred, corrected, deleted, or subjected to automated decisions.

Example: Assess whether the collection and use are lawful, necessary, transparent, purpose-limited, and rights-compatible in addition to securing the data.

Counterexample: Approve the personal-data processing because encryption protects confidentiality, without assessing whether the processing is lawful or necessary. | Ask only whether unauthorized disclosure is prevented and omit purpose, transparency, fairness, and rights. | Approve collection first and decide whether the processing was appropriate after deployment, and retention and backup behavior would still conflict with the approved privacy outcome.

Data collection scope

The defined set of personal data, sources, purposes, users, collection methods, legal basis, and populations covered by processing.

Example: Limit collection to the personal data, sources, populations, and methods necessary for the specified fraud purpose and document the applicable lawful basis.

Counterexample: Collect the broad telemetry now because it may be useful for unspecified future purposes, and the processing would still lack a defensible purpose and rights basis. | Collect every requested field after listing a broad purpose such as service improvement, and the change would preserve the same re-identification or function-creep risk. | Minimize only what is displayed to users while retaining the full raw data indefinitely, and cross-border authority and remote-access conditions would remain undefined.

Data minimization

Limiting collection, processing, access, and retention to data reasonably necessary for the approved purpose.

Example: Remove unnecessary historical data, access, processing, and retention as well as stopping future collection.

Counterexample: Stop collecting the optional field but keep unlimited internal access and indefinite historical retention. | Collect the full data set and minimize only the copy shown in the user interface. | Keep unnecessary data because storage is inexpensive and future use is uncertain.

Purpose limitation

Using personal data only for specified, legitimate, compatible, and approved purposes.

Example: Require a new compatibility, lawful-basis, notice or consent, privacy, security, and risk review before reusing the transcripts.

Counterexample: Reuse the support transcripts because the new model benefits customers, without assessing compatibility or lawful basis. | Update the privacy notice after deployment and treat that notice as retroactive authorization. | Remove direct identifiers but leave the new employee-scoring purpose and access unchanged, and identity, legal exceptions, and evidence would remain unresolved.

Notice and transparency

Requirements to communicate what data is collected, why, how it is used, with whom it is shared, how long it is retained, and what rights individuals have.

Example: Provide a clear privacy notice covering data collected, purposes, sharing, retention, and rights instead of relying on unrelated contractual language.

Counterexample: Place material collection, sharing, retention, and rights information only in unrelated terms of service, and retention and backup behavior would still conflict with the approved privacy outcome. | Provide a notice that lists data categories but omits purposes, recipients, retention, and rights, and the processing would still lack a defensible purpose and rights basis. | Show the notice only after processing has started and provide no record of the version presented.

Consent

A recorded indication of agreement where consent is the applicable lawful basis.

Example: Obtain granular, timely, withdrawable, versioned consent only where consent is the applicable lawful basis, and preserve proof.

Counterexample: Use one checkbox to make every proposed processing purpose lawful, and cross-border authority and remote-access conditions would remain undefined. | Treat refusal of an optional-processing checkbox as grounds to deny the core service. | Record the initial checkbox but provide no withdrawal, versioning, purpose granularity, or proof.

Pseudonymization

Replacing direct identifiers with pseudonyms while keeping additional information that can restore or link identity under controlled conditions.

Example: Continue treating the tokenized records as personal data and protect the re-linking information separately under controlled access.

Counterexample: Call the tokenized records anonymous because direct names are absent, and the processing would still lack a defensible purpose and rights basis. | Store the token map with the data and permit the same operators to access both without additional controls. | Remove the personal-data requirements while the organization can still restore identity, and cross-border authority and remote-access conditions would remain undefined.

Anonymization

Transforming data so individuals are not reasonably identifiable using means reasonably likely to be available, considering linkage and inference risks.

Example: Evaluate identifiability using dates, location, rarity, linkage data, recipient capability, cost, time, and available technology before calling the data anonymous.

Counterexample: Declare the data anonymous after deleting names and email addresses, and identity, legal exceptions, and evidence would remain unresolved. | Assess only whether the organization itself can re-identify people and ignore recipient and external-data capabilities. | Use reversible tokenization and label the result fully anonymized, and the processing would still lack a defensible purpose and rights basis.

Re-identification risk

The possibility that anonymized or pseudonymized data can be linked back to individuals through unique attributes, external data, small groups, or inference.

Example: Assess the released data, recipients, auxiliary sources, uniqueness, linkage methods, and attack capability, then strengthen de-identification or restrict release.

Counterexample: Assess only whether names are present and ignore external data and unique combinations, and retention and backup behavior would still conflict with the approved privacy outcome. | Rely on a contract clause prohibiting re-identification instead of evaluating technical and contextual risk. | Release the full data set to a broader audience because the internal team could not re-identify anyone.

Legal rights of individuals

Depending on applicable law, rights may include notice, access, correction, deletion, restriction, objection, portability, consent withdrawal, and safeguards for automated decisions.

Example: Verify the requester, track the request, apply the relevant right and exceptions, meet the response deadline, protect other individuals, and retain evidence.

Counterexample: Implement deletion requests without verifying the requester or protecting against deletion of another person’s data, and cross-border authority and remote-access conditions would remain undefined. | Fulfill the request without tracking deadlines, exceptions, scope, and evidence, and identity, legal exceptions, and evidence would remain unresolved. | Require no identity verification for correction and portability because those actions do not delete data, and retention and backup behavior would still conflict with the approved privacy outcome.

Right to erasure / right to be forgotten

A right to request deletion under applicable conditions, subject to exceptions such as legal retention, fraud prevention, litigation hold, public interest, or security investigation.

Example: Delete eligible data after identity and applicability checks, preserve records covered by valid exceptions, control backups, and document the decision.

Counterexample: Delete every copy immediately without verifying the requester or checking legal retention, fraud, investigation, or litigation exceptions. | Reject every deletion request because backup copies cannot be changed immediately, and the change would preserve the same re-identification or function-creep risk. | Delete active records but allow restored backups to return the data to routine use without re-deletion.

“Data disposal” as a rights and preferences example

The official outline lists “data disposal” under user rights and preferences.

Example: Treat the request as a privacy rights or preference workflow subject to identity, applicability, retention, and exception rules, not as routine media destruction.

Counterexample: Execute the individual’s disposal preference as routine media destruction without a privacy-rights applicability and exception workflow, and identity, legal exceptions, and evidence would remain unresolved. | Treat the preference as an unconditional order to erase every active, backup, and legally retained copy, and retention and backup behavior would still conflict with the approved privacy outcome. | Ignore the request because organizational disposal follows a separate lifecycle process, and the processing would still lack a defensible purpose and rights basis.

User preferences

Configurable choices such as marketing, personalization, cookies, third-party sharing, push notifications, location, and optional telemetry.

Example: Implement the user’s configurable choice while keeping legal rights, mandatory service processing, and preference evidence distinct.

Counterexample: Treat the disabled personalization setting as a request to delete all account and service records. | Ignore the preference because it is not a statutory right, and cross-border authority and remote-access conditions would remain undefined. | Bundle optional tracking, marketing, notifications, and location into one irreversible setting, and identity, legal exceptions, and evidence would remain unresolved.

Terms of service

Contractual terms governing use of a service.

Example: Keep contractual acceptance separate from a clear privacy notice and any consent or other lawful-basis requirement.

Counterexample: Use acceptance of the terms of service as proof of clear privacy notice and valid consent. | Place privacy details in a link that is available only after account creation. | Treat contractual permission as a substitute for data minimization and purpose limitation.

Privacy retention requirement

Defines what personal data is retained, the purpose and authority, duration or trigger, location, archival treatment, legal holds, backup behavior, and disposal evidence.

Example: Define the retained data, purpose, authority, duration or trigger, location, archive and legal-hold behavior, backup treatment, deletion, and evidence.

Counterexample: Use “retain as long as necessary” without defining the authority, decision rule, trigger, or evidence. | Set one retention period for all personal data without purpose, legal, or category distinctions. | Define deletion timing but omit archives, legal holds, backups, restored copies, and evidence, and retention and backup behavior would still conflict with the approved privacy outcome.

Backups and deletion

Requirements must address whether deletion can occur in backups, whether backups are isolated from routine use, how restored data is re-deleted, and when backup copies expire.

Example: Isolate backups from routine use, define expiration, ensure restored data is re-deleted, and document any limits on immediate backup deletion.

Counterexample: Reject the deletion request because backups cannot be edited immediately, and the processing would still lack a defensible purpose and rights basis. | Delete active data but permit restored backups to return it to normal processing, and the change would preserve the same re-identification or function-creep risk. | Erase backup media immediately even when doing so would violate an approved recovery or legal-retention requirement.

Data residency

A requirement that data be stored or processed in a specified geographic location or region.

Example: Require storage and processing within the named region and separately assess remote access, jurisdiction, sovereignty, and transfer conditions.

Counterexample: Treat data residency as proof that only the storage country’s law can apply, and cross-border authority and remote-access conditions would remain undefined. | Permit foreign administrators to view the data because the storage location remains unchanged. | Replace the regional location requirement with a general promise to follow applicable law.

Data sovereignty

The principle that data is subject to laws and governmental authority associated with a nation or jurisdiction.

Example: Identify the governmental and legal authority that can apply to the data even when its physical storage location is unchanged.

Counterexample: Use the physical storage location as the sole definition of sovereignty, and the change would preserve the same re-identification or function-creep risk. | Assume moving data to another region automatically changes every applicable legal authority, and cross-border authority and remote-access conditions would remain undefined. | Treat sovereignty, residency, and jurisdiction as interchangeable labels, and identity, legal exceptions, and evidence would remain unresolved.

Jurisdiction

The legal authority applicable to the organization, processing activity, data subject, contract, system, or data location.

Example: Map every applicable jurisdiction to the organization, users, contracts, processing activities, systems, and data locations, then resolve conflicts.

Counterexample: Choose the data-center location as the only applicable jurisdiction, and retention and backup behavior would still conflict with the approved privacy outcome. | Let developers resolve conflicts among user, contract, processing, and organizational jurisdictions, and the processing would still lack a defensible purpose and rights basis. | Apply the strictest known rule globally without documenting applicability or conflict resolution, and the change would preserve the same re-identification or function-creep risk.

Cross-border processing boundary

A defined constraint on international storage, access, support, transfer, subprocessors, and remote administration.

Example: Treat foreign remote administration as cross-border processing and specify permitted countries, roles, safeguards, subprocessors, logging, and approvals.

Counterexample: Treat remote administration from another country as domestic processing because the database does not move. | Allow any overseas support team to access production after signing a confidentiality agreement. | Restrict only storage location and omit international access, subprocessors, support, and transfer conditions.

Privacy by design and by default

Embedding privacy principles into requirements, architecture, defaults, interfaces, lifecycle controls, and evidence from the beginning.

Example: Set privacy-protective defaults for optional tracking, visibility, sharing, and telemetry, while allowing informed user changes.

Counterexample: Enable optional tracking and sharing by default and rely on users to discover the settings later. | Add privacy controls only after architecture and interfaces are complete, and the change would preserve the same re-identification or function-creep risk. | Treat a privacy notice as sufficient evidence that privacy-protective defaults are implemented.

Function creep

Expansion of data use or system capability beyond its original purpose without adequate governance, risk, privacy, or stakeholder review.

Example: Block the new use until renewed business, privacy, legal, security, and risk review approves the expanded purpose and data access.

Counterexample: Approve the new employee-scoring use because the existing model and data make it technically possible. | Use the support-purpose approval as authorization for employee scoring because the same transcripts are used. | Remove names from the transcripts and proceed without reviewing the new purpose, affected people, or decision impact.

Right to data portability

Where applicable law grants data portability, the system must support verified requests and provide the covered personal data in a structured, commonly used, machine-readable format.

Example: After verifying scope and identity, provide covered data in a structured, commonly used, machine-readable format through a secure delivery process.

Counterexample: Require one proprietary export for every portability request and include every item the organization holds. | Send a readable PDF and treat access and portability as identical in every case, and cross-border authority and remote-access conditions would remain undefined. | Export covered data together with other individuals’ data and internal risk notes because they appear in the same record.

Regulatory consequence of pseudonymization and anonymization

Under the GDPR, pseudonymized data remains personal data when it can be attributed to a person using additional information.

Example: Keep pseudonymized or reversibly tokenized data within personal-data controls, changing regulatory treatment only after effective anonymization is demonstrated in context.

Counterexample: Treat removed names, hashing, masking, tokenization, or encryption as conclusive anonymization, and retention and backup behavior would still conflict with the approved privacy outcome. | Move pseudonymized data outside privacy governance while the re-linking key remains available, and the processing would still lack a defensible purpose and rights basis. | Call the data anonymous based only on the transformation technique and omit contextual re-identification analysis.

Access provisioning

The controlled lifecycle for requesting, approving, creating, modifying, reviewing, suspending, and revoking identities and entitlements.

Example: Use a controlled request, approval, assignment, review, suspension, and revocation process, because authentication alone does not authorize the entitlement.

Counterexample: Treat successful authentication as approval to assign the requested entitlement, and emergency or privileged activity would remain unauditable. | Create the entitlement after a successful MFA login without a request, approval, owner, or duration. | Treat access provisioning as a one-time account-creation event and omit modification, review, suspension, and revocation.

User provisioning

Creating and maintaining a unique user identity and assigning access based on approved business need, role, attributes, risk, and least privilege.

Example: Create a unique identity and grant only the permissions justified by approved business need, role, attributes, risk, and least privilege.

Counterexample: Create a shared department account so new users can start immediately, and obsolete or conflicting access would remain active. | Copy the access of the most senior team member to avoid missing permissions, and credential ownership, rotation, review, and revocation would remain incomplete. | Grant all requested access permanently and rely on later monitoring to detect misuse, and emergency or privileged activity would remain unauditable.

Joiner process

Establishing identity, approvals, baseline access, training prerequisites, and time-bound or role-based entitlements for a new worker or user.

Example: Complete identity establishment, accountable approval, prerequisite training, and time- or role-bounded baseline access before activation.

Counterexample: Activate the account before identity proofing and training, then collect approval afterward. | Give the new analyst the department’s full access bundle with no expiration. | Let the hiring manager create the account directly without an auditable provisioning request.

Mover process

Reevaluating and changing access when duties, department, project, location, or employment relationship changes.

Example: Remove obsolete and conflicting payroll access before or while granting the procurement permissions required for the new role.

Counterexample: Add procurement access and leave all payroll permissions until the next annual review. | Clone the access of another procurement employee without evaluating the mover’s existing entitlements. | Let the employee retain both approval roles because each permission was separately authorized in the past.

Leaver process

Promptly disabling identities, sessions, tokens, certificates, remote access, and physical access when the relationship ends, while preserving required evidence and records.

Example: Promptly disable identities, sessions, tokens, certificates, remote and physical access, while preserving required records and evidence.

Counterexample: Disable the user account at the end of the next scheduled batch process. | Revoke interactive login but leave sessions, API tokens, certificates, VPN, and physical access active. | Delete the identity record immediately and lose the evidence needed for investigation and records retention.

Least privilege in provisioning

Granting only the minimum operations, data, scope, environment, and duration needed for approved duties.

Example: Limit operations, data, environment, and duration to the minimum approved need, then maintain that limit through review and revocation.

Counterexample: Grant production-wide access because reducing the scope would delay the project, and emergency or privileged activity would remain unauditable. | Use the job title as proof that every permission in the role is necessary. | Apply least privilege only at account creation and skip later reviews and revocation, and the process would not prevent privilege accumulation after role changes.

Role-based access control (RBAC)

Assigning permissions to roles and users to roles.

Example: Redesign and govern roles so permissions reflect current duties, least privilege, and segregation-of-duties constraints rather than assuming RBAC guarantees them.

Counterexample: Keep the existing roles because using RBAC automatically proves least privilege, and obsolete or conflicting access would remain active. | Create a separate role for every individual exception and allow uncontrolled role growth, and credential ownership, rotation, review, and revocation would remain incomplete. | Assign users directly to permissions whenever a role contains one unnecessary privilege, and emergency or privileged activity would remain unauditable.

Attribute-based access control (ABAC)

Evaluating subject, object, action, environment, and policy attributes to make authorization decisions.

Example: Use trustworthy, governed subject, object, action, and environment attributes with defined policy behavior and failure handling.

Counterexample: Trust location and device attributes supplied by the requesting client without validation. | Fall back to allow when an attribute is missing or the policy service is unavailable. | Use ABAC for every decision even when a simple stable role requirement would be clearer.

Service account

A non-human identity used by software, automation, jobs, workloads, or integrations.

Example: Assign a named owner and purpose, remove interactive login, restrict privilege, protect and rotate credentials, log use, review access, and decommission the account.

Counterexample: Keep the shared service account and rotate its long-lived password once a year, and credential ownership, rotation, review, and revocation would remain incomplete. | Move the password into a vault but retain excessive privilege, interactive login, and no owner, and emergency or privileged activity would remain unauditable. | Create one service account for all environments so troubleshooting is easier, and the business owner would still have no basis for approving the entitlement.

Workload identity

A cryptographically established identity for a service or workload, often using short-lived credentials, federation, certificates, or platform identity instead of stored passwords.

Example: Use a cryptographically established workload identity with short-lived, automatically rotated credentials or federation instead of a stored password.

Counterexample: Store one static password in the container image and rotate it during annual maintenance. | Share a long-lived API key among all workload replicas, and obsolete or conflicting access would remain active. | Use the workload’s network address as its identity without cryptographic proof, and credential ownership, rotation, review, and revocation would remain incomplete.

Service-account credential management

Requirements for approved secret storage, non-hardcoding, rotation, revocation, environment separation, access logging, and emergency replacement.

Example: Keep the secret in an approved store, reduce the account’s privilege, separate environments, rotate and revoke credentials, log access, and define emergency replacement.

Counterexample: Move the secret to a vault and leave the account’s privilege, owner, rotation, and review unchanged, and emergency or privileged activity would remain unauditable. | Use the same credential in development, test, and production, and the business owner would still have no basis for approving the entitlement. | Rotate the credential periodically but provide no emergency revocation or replacement process, and the process would not prevent privilege accumulation after role changes.

Privileged account

An identity with elevated administrative, security, or system-control permissions.

Example: Require a separate privileged identity with MFA, PAM or just-in-time controls, session oversight, and prohibition on routine use.

Counterexample: Use the privileged account for email and web browsing because MFA is enabled. | Share one administrator identity among the operations team for easier support, and credential ownership, rotation, review, and revocation would remain incomplete. | Grant standing administrative access and omit session recording, just-in-time approval, and enhanced review.

Reapproval / recertification

Periodic or event-driven confirmation by an accountable owner that access remains necessary, appropriate, and free of prohibited conflicts.

Example: Have the accountable business, data, or application owner confirm ongoing need, appropriateness, and absence of prohibited conflicts.

Counterexample: Let the IAM administrator recertify every entitlement based on whether the account is technically active. | Keep access when the owner does not respond and record silence as approval. | Review only user accounts and exclude service, privileged, and high-risk entitlements, and obsolete or conflicting access would remain active.

Reapproval triggers

Time interval, role change, project completion, high-risk privilege, organizational change, incident, inactivity, classification change, or system migration.

Example: Trigger reapproval on the high-risk entitlement now because role change, incident, inactivity, and migration each invalidate the annual-only schedule.

Counterexample: Wait for the annual review despite the role change, incident, inactivity, and migration, and credential ownership, rotation, review, and revocation would remain incomplete. | Trigger reapproval only when the user requests additional access, and emergency or privileged activity would remain unauditable. | Treat a successful login after migration as confirmation that the entitlement remains appropriate, and the business owner would still have no basis for approving the entitlement.

Privilege creep

Accumulation of permissions that are no longer necessary because access was added over time without removing prior entitlements.

Example: Remove permissions no longer required for current duties and use mover controls plus periodic recertification to prevent reaccumulation.

Counterexample: Keep all historical permissions because each was approved at the time it was granted. | Add a new role and rely on monitoring instead of removing obsolete access, and credential ownership, rotation, review, and revocation would remain incomplete. | Review only the most recent entitlement and ignore permissions inherited from prior roles.

Orphan account

An account lacking a valid, accountable owner or no longer associated with an authorized person, service, or business purpose.

Example: Investigate the account, identify any valid owner or purpose, disable it when none exists, and preserve relevant activity evidence.

Counterexample: Leave the account enabled until someone claims ownership, and emergency or privileged activity would remain unauditable. | Delete the account immediately without preserving activity evidence or checking dependencies, and the business owner would still have no basis for approving the entitlement. | Assign the account to the IAM team as a placeholder owner without a business purpose.

Segregation of duties in access

Preventing one identity from holding a prohibited combination of permissions that enables fraud, error concealment, or unilateral high-risk action.

Example: Prevent or require independent approval for the toxic combination of supplier creation, payment-detail approval, and payment release.

Counterexample: Allow the user to keep all three permissions because each belongs to the same job family. | Rely on transaction logging after payment rather than preventing the toxic combination, and credential ownership, rotation, review, and revocation would remain incomplete. | Ask the user to self-certify that the conflicting access will not be abused.

Emergency or break-glass access

Exceptional elevated access designed for urgent recovery, with restricted custody, strong authentication, logging, immediate review, and prompt revocation or credential rotation.

Example: Restrict custody, require strong authentication and logging, review use immediately, revoke access, and rotate the credential after the emergency.

Counterexample: Keep the shared emergency credential active and unchanged after the outage, and the business owner would still have no basis for approving the entitlement. | Exclude break-glass activity from monitoring because the event is urgent, and the process would not prevent privilege accumulation after role changes. | Allow routine administrators to use the account whenever normal approval is inconvenient, and obsolete or conflicting access would remain active.

Access-control policy models as requirements constraints

Access requirements may be expressed through discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), attribute-based access control (ABAC), or a combination.

Example: State the required policy outcomes for mandatory labels, business roles, delegation, and contextual attributes, while Domain 4 designs the combined enforcement.

Counterexample: Choose one access-control model as universally strongest and prohibit combining mandatory labels, roles, delegation, and contextual attributes. | Specify only RBAC even though mandatory labels and contextual attributes are required by policy, and emergency or privileged activity would remain unauditable. | Prescribe a detailed enforcement architecture instead of stating the required delegation, label, role, and attribute outcomes.

Misuse case

A scenario describing unintended, incorrect, prohibited, or harmful use of system functionality.

Example: Model the prohibited or harmful workflow, including accidental repeated use, its preconditions, affected asset, impact, and the requirements needed to limit, detect, or recover.

Counterexample: Classify the repeated refund only as malicious abuse and omit accidental or incorrect use, and the abuse path could succeed even though individual inputs appear valid. | Document the normal refund use case and assume it covers repeated or prohibited execution, and the adverse path would remain unlinked to a bounded security outcome. | Select a fraud product without defining the prohibited sequence, limit, detection, or recovery outcome, and residual risk would still lack an accountable treatment decision.

Abuse case

A scenario describing how an adversary or malicious user intentionally exploits functionality, workflow, trust, data, or interfaces to achieve a harmful objective.

Example: Model the malicious reseller’s goal, capability, trust position, manipulated sequence, affected assets, and required preventive and detective outcomes.

Counterexample: Treat the authenticated reseller as a legitimate actor and exclude intentional workflow manipulation from the analysis. | Describe only malformed inputs and ignore deliberate use of valid functions in an unauthorized sequence. | Record the attacker’s steps without the malicious objective, affected assets, and derived requirements.

Threat actor

The person, group, service, workload, supplier, or compromised identity capable of performing the adverse action.

Example: Include internal, external, human, service, supplier, bot, administrator, and compromised-identity actors with their capability, access, motivation, and trust position.

Counterexample: Model only unauthenticated internet attackers and exclude trusted or compromised identities, and the proposal would not establish whether prevention, detection, correction, or recovery is required. | List actor names without capability, access, motivation, or trust position, and the abuse path could succeed even though individual inputs appear valid. | Treat the supplier and service account as system components rather than possible threat actors.

Abuse objective

The harmful outcome sought, such as unauthorized disclosure, fraud, account takeover, privilege escalation, denial of service, policy bypass, model manipulation, or evidence destruction.

Example: State the attacker’s harmful objective and affected business outcome so requirements can target fraud, disclosure, takeover, denial, bypass, or evidence destruction.

Counterexample: Describe the API calls but omit the attacker’s intended fraud or harm, and residual risk would still lack an accountable treatment decision. | Use “compromise the system” as the objective without identifying assets or business impact, and the SRTM would not connect the scenario to controls, tests, and evidence. | Assume every adverse scenario has the same confidentiality objective, and the proposal would not establish whether prevention, detection, correction, or recovery is required.

Preconditions and attack path

The required state, privileges, data, sequence, interface, and trust-boundary transitions that make the adverse scenario possible.

Example: Document the required account, privileges, sequence, race window, interfaces, and trust-boundary transitions, then derive requirements that remove, constrain, or detect them.

Counterexample: Document the final harmful action but omit the required account, privileges, sequence, and race window, and the abuse path could succeed even though individual inputs appear valid. | Assume the path is impossible because each individual step is authorized, and the adverse path would remain unlinked to a bounded security outcome. | Model only network entry and ignore trust-boundary transitions inside the application workflow, and residual risk would still lack an accountable treatment decision.

Business-logic abuse

Exploitation of valid functions or workflow assumptions rather than a classic coding flaw, such as repeated promotions, self-approval, race conditions in inventory, or unauthorized sequence changes.

Example: Require server-side controls for redemption limits, independent approval, atomic inventory or credit updates, and valid workflow sequencing.

Counterexample: Add stricter input-format validation and assume valid repeated redemption and self-approval are prevented. | Block all promotion use after one redemption without considering legitimate business rules or recovery. | Log the workflow but omit authorization, limits, sequence enforcement, and atomic state changes.

Negative requirement derivation

Turning an adverse scenario into a testable statement of behavior the system must deny, limit, detect, or recover from.

Example: Translate the scenario into bounded requirements that deny or limit the action, record attempts, trigger response, and support recovery.

Counterexample: Write only “prevent fraud” and leave denied behavior, limits, detection, and recovery undefined, and the adverse path would remain unlinked to a bounded security outcome. | Derive a logging requirement but no preventive or corrective outcome, and residual risk would still lack an accountable treatment decision. | Copy the abuse narrative into the requirement without a testable subject, condition, and behavior.

Mitigating control identification

Selecting candidate preventive, detective, corrective, deterrent, recovery, or compensating safeguards that reduce likelihood or impact.

Example: Identify the necessary preventive, detective, corrective, recovery, deterrent, or compensating outcomes before selecting specific mechanisms.

Counterexample: Select a fraud-detection product before defining the required prevention, detection, recovery, or compensation outcome. | Choose only a preventive control and ignore detection, correction, and residual impact. | List possible safeguards without linking them to the scenario, risk reduction, or verification.

Preventive control

A safeguard intended to stop or constrain an adverse action before harm occurs, such as authorization, transaction limits, separation of duties, or validation.

Example: Require the transaction to be denied before completion when the approval limit or segregation rule fails.

Counterexample: Log the prohibited transaction after completion but do not block it, and residual risk would still lack an accountable treatment decision. | Ask an operator to review every transaction manually instead of enforcing the approval limit. | Reject every transaction above a fixed amount without considering the approved role and business rule.

Detective control

A safeguard that identifies attempted or successful misuse, such as audit logging, anomaly detection, rate monitoring, and alerts.

Example: Require security events, correlation, rate or anomaly thresholds, alerts, and accountable response for repeated restricted-record probing.

Counterexample: Block the account after one failed lookup and omit observable events and accountable response. | Store logs with no threshold, alert, correlation, or review requirement, and the adverse path would remain unlinked to a bounded security outcome. | Use a dashboard count but omit actor, target, timing, outcome, and escalation context.

Corrective and recovery control

A safeguard that contains damage, restores an approved state, revokes access, repairs data, or resumes service after an event.

Example: Require containment, access revocation, restoration of approved payment data, integrity verification, and safe service recovery.

Counterexample: Restore service without revoking the compromised access or verifying payment-data integrity. | Revoke access but leave altered payment instructions and interrupted transactions unresolved. | Write only a backup requirement and omit containment, correction, and safe resumption.

Compensating control

An alternative safeguard providing comparable risk reduction when the primary control is infeasible, with documented rationale and residual risk.

Example: Document primary-control infeasibility, require comparable risk reduction from the alternative, verify it, and obtain authority for the remaining risk.

Counterexample: Use the weaker manual review because it is easier, without comparing risk reduction to the primary control. | Call any alternative safeguard a compensating control once management approves the schedule, and residual risk would still lack an accountable treatment decision. | Document the alternative but omit validation, residual risk, owner, expiration, and review trigger, and the SRTM would not connect the scenario to controls, tests, and evidence.

Residual risk

Risk remaining after controls are specified or applied.

Example: Measure the residual likelihood and impact against risk tolerance and obtain treatment or acceptance from the proper business authority.

Counterexample: Declare the risk eliminated because the selected controls passed testing, and the proposal would not establish whether prevention, detection, correction, or recovery is required. | Let the security analyst accept the remaining business exposure, and the abuse path could succeed even though individual inputs appear valid. | Record residual risk without comparing it to tolerance or assigning treatment and review, and the adverse path would remain unlinked to a bounded security outcome.

Misuse/abuse traceability

Linking the adverse scenario to affected assets, risks, security requirements, controls, test cases, evidence, and residual-risk decisions.

Example: Link the adverse scenario to affected assets, risk, derived requirements, controls, tests, evidence, and residual-risk decisions in the SRTM.

Counterexample: Link the abuse case only to one test and omit assets, risks, controls, evidence, and decisions. | Store the trace links in analyst notes outside the controlled SRTM, and the SRTM would not connect the scenario to controls, tests, and evidence. | Close the abuse case when a requirement is written, before implementation and verification links exist.

Security Requirements Traceability Matrix (SRTM)

A controlled mapping that connects security requirements to their sources, risks, designs, implementations, verification activities, evidence, ownership, status, and exceptions.

Example: Expand the SRTM to map each requirement to its source, risk, owner, design, implementation, verification, evidence, status, and exceptions.

Counterexample: Keep the spreadsheet as a list of test cases because testing is the final proof of every requirement. | Add requirement text but omit sources, risks, design, implementation, evidence, ownership, status, and exceptions. | Use separate documents with no stable links or version control and call the collection an SRTM.

Forward traceability

Tracing from source or requirement to design, implementation, test, evidence, and release decision.

Example: Trace each approved source and requirement forward through design, implementation, tests, evidence, and release decision.

Counterexample: Trace only from the test result back to a requirement and omit whether all approved requirements reached implementation. | Stop the forward trace at design and do not link code, configuration, evidence, or release decision. | Count a requirement as covered when any downstream artifact has the same title.

Backward traceability

Tracing from a control, component, test, or feature back to an approved requirement and source.

Example: Trace each control, component, feature, and test backward to an approved requirement and authoritative source, then resolve unsupported work.

Counterexample: Keep the new control because it appears useful even though no approved requirement or source supports it. | Trace only tests backward and ignore unsupported features, components, and configurations, and material changes would not propagate to every affected artifact and stakeholder. | Create a new requirement after implementation solely to justify the existing control, and the release decision would still depend on stale or incomplete trace links.

Bidirectional traceability

Maintaining both forward and backward links so coverage and justification can be evaluated in either direction.

Example: Maintain both forward and backward links so reviewers can establish implementation coverage and business justification in either direction.

Counterexample: Maintain only forward links because every implementation should already have an approved reason. | Maintain only backward links because tests can reveal which requirements matter, and the matrix would still hide valid many-to-many relationships. | Force each artifact into one link and discard valid many-to-many relationships, and the relationship would not establish either coverage or business justification.

Coverage analysis

Using the matrix to identify requirements without design, implementation, tests, results, evidence, or owners, and risks or obligations without requirements.

Example: Use the matrix to find requirements, risks, or obligations missing designs, implementations, tests, results, evidence, owners, or sufficient test depth.

Counterexample: Treat one linked test as proof that every risk condition and environment is covered, and material changes would not propagate to every affected artifact and stakeholder. | Count only requirements with no test and ignore missing design, implementation, evidence, owner, and source links. | Measure code coverage and use it as a substitute for SRTM gap analysis, and evidence could belong to the wrong version or environment.

Change impact analysis

Using traceability to identify designs, code, tests, operations, contracts, evidence, and stakeholders affected by a requirement, regulatory, architecture, or risk change.

Example: Follow the changed requirement’s links and update affected design, code, configuration, tests, operations, contracts, evidence, stakeholders, and release decisions.

Counterexample: Edit only the requirement text and leave designs, code, tests, operations, contracts, and evidence unchanged. | Update the test cases but omit stakeholders, release decisions, and downstream vendor obligations, and the relationship would not establish either coverage or business justification. | Create a new requirement with no link to the prior version or impacted artifacts.

Unique identifiers and versioning

Stable IDs and controlled versions allow reliable links, baselines, auditability, and change history.

Example: Issue a new controlled version or identifier for the materially changed requirement and preserve the old baseline and link history.

Counterexample: Reuse the old identifier so dashboards continue to show the requirement as verified, and the release decision would still depend on stale or incomplete trace links. | Overwrite the old requirement text and delete the previous baseline, and evidence could belong to the wrong version or environment. | Change identifiers on every editorial correction and break stable links unnecessarily, and the matrix would still hide valid many-to-many relationships.

Requirement status

Typical states include proposed, analyzed, approved, implemented, verified, deferred, waived, rejected, and retired.

Example: Define controlled states such as proposed, analyzed, approved, implemented, verified, deferred, waived, rejected, and retired, with explicit transition authority.

Counterexample: Let each team interpret done, closed, and accepted differently, and the relationship would not establish either coverage or business justification. | Mark a requirement verified when implementation is complete but testing has not run, and material changes would not propagate to every affected artifact and stakeholder. | Allow status transitions without identifying the role authorized to approve them, and the release decision would still depend on stale or incomplete trace links.

Exception and risk-acceptance traceability

Approved deviations must identify scope, rationale, compensating controls, residual risk, owner, approver, expiration, and review trigger.

Example: Record the exception’s scope, rationale, compensating controls, residual risk, owner, approver, expiration, and review trigger, because a ticket alone is not acceptance.

Counterexample: Treat the remediation ticket as evidence that the high-risk defect is accepted, and evidence could belong to the wrong version or environment. | Record only the approver’s name and omit scope, rationale, controls, risk, expiration, and trigger, and the matrix would still hide valid many-to-many relationships. | Keep the exception open indefinitely because remediation is planned, and the relationship would not establish either coverage or business justification.

Evidence linkage

The matrix should reference objective evidence such as test results, configuration records, sign-offs, assessment reports, and operational telemetry.

Example: Link evidence from the applicable requirement version, implementation, environment, and test execution rather than an older staging report.

Counterexample: Use the staging test report because the requirement ID matches the production release, and the relationship would not establish either coverage or business justification. | Link to a document folder rather than the applicable test result and environment. | Accept evidence from the current version but a different configuration with no equivalence analysis.

Many-to-many relationships

One requirement may map to several controls and tests; one control may satisfy several requirements; one external clause may produce many requirements.

Example: Represent the valid many-to-many links among clauses, requirements, controls, implementations, and tests without forcing artificial one-to-one rows.

Counterexample: Split one shared control into duplicate controls so each requirement can have a unique row. | Choose one requirement as the official source and remove the other valid obligations. | Count rows as coverage even though the artificial one-to-one mapping hides shared implementation and tests.

Traceability versus test coverage

Traceability establishes relationships among artifacts.

Example: Use traceability to prove relationships and separate coverage measures to show what behavior, paths, code, requirements, and risks were actually exercised.

Counterexample: Treat bidirectional links and high code coverage together as proof that the product is secure, and the release decision would still depend on stale or incomplete trace links. | Use traceability percentage as the only measure of testing depth, and evidence could belong to the wrong version or environment. | Remove trace links because test coverage already shows exercised code and paths, and the matrix would still hide valid many-to-many relationships.

Third-party vendor security requirement

A documented security, privacy, resilience, evidence, or lifecycle obligation that a supplier must satisfy as a condition of selection, integration, acceptance, operation, renewal, or termination.

Example: Define enforceable supplier security, privacy, resilience, evidence, acceptance, oversight, renewal, and termination requirements before selection or integration.

Counterexample: Sign the contract first and add security obligations after integration, and customer and supplier responsibilities would still be ambiguous. | Use a voluntary questionnaire response instead of an enforceable requirement, and the evidence would not establish the applicable service, scope, or current risk. | Define only initial acceptance criteria and omit operation, renewal, change, and termination obligations.

Vendor scope

Third parties include SaaS, cloud providers, identity and payment services, outsourced developers, managed services, data processors, APIs, commercial software, component suppliers, AI model providers, and relevant subcontractors.

Example: Include the direct provider, relevant subcontractors, hosting, identity, payment, development, data-processing, API, component, and model dependencies in vendor scope.

Counterexample: Limit vendor scope to the company named on the direct contract, and material subcontractor and lifecycle changes would remain outside oversight. | Exclude the model provider and subprocessors because the SaaS vendor manages them, and exit, deletion, and transition obligations would remain unresolved. | Assess only suppliers that store data and omit privileged APIs, identity services, components, and outsourced development.

Risk-based tailoring

Requirements should reflect data sensitivity, privilege, integration depth, business criticality, substitutability, concentration risk, jurisdiction, and impact of failure or compromise.

Example: Tailor obligations and evidence to data sensitivity, privilege, integration depth, criticality, substitutability, concentration, jurisdiction, and failure impact.

Counterexample: Apply the payment processor’s controls and evidence demands to the low-risk office tool. | Tailor requirements only by contract value and ignore privilege, data, criticality, and failure impact. | Reduce requirements for a concentrated single-source supplier because replacement is difficult, and material subcontractor and lifecycle changes would remain outside oversight.

Secure development requirement

Supplier obligations for secure SDLC, training, threat modeling, coding standards, code review, testing, dependency management, build integrity, vulnerability handling, and release security.

Example: Put the required secure-development practices, evidence, remediation, and acceptance conditions into enforceable supplier artifacts, tailored to risk.

Counterexample: Accept the supplier’s statement that it follows a framework without enforceable practices or evidence. | Insert every SSDF practice into the contract without tailoring to service scope and risk. | Require penetration testing but omit training, code review, dependencies, build integrity, and vulnerability handling.

Identity and access requirement

Supplier obligations for unique identities, MFA, least privilege, privileged access, service accounts, recertification, termination, and access logging.

Example: Require unique identities, MFA, least privilege, privileged and service-account controls, recertification, termination, and access logging for supplier personnel.

Counterexample: Allow shared administrator accounts if the provider logs the source IP, and the promise would remain outside an enforceable supplier obligation. | Require MFA for users but omit service accounts, privileged access, recertification, termination, and logging. | Let the provider decide when former personnel lose customer-environment access, and exit, deletion, and transition obligations would remain unresolved.

Data protection requirement

Supplier obligations for classification, approved use, segregation, encryption, key management, residency, retention, backup, return, and secure deletion.

Example: Define classification, permitted use, segregation, protection outcomes, key responsibilities, residency, retention, backup, return, deletion, and evidence.

Counterexample: Use “protect customer data” as the complete clause without classification, use, location, retention, return, or deletion terms. | Permit regional copies when encrypted even though residency and approved use are undefined. | Assign encryption to the supplier but leave customer key, access, backup, and deletion responsibilities unspecified.

Vulnerability management requirement

Supplier obligations for discovery, severity assessment, remediation targets, customer notification, coordinated disclosure, patch delivery, and verification.

Example: Define discovery and severity methods, remediation deadlines, notification triggers, coordinated disclosure, patch delivery, verification, and unresolved-risk handling.

Counterexample: Require patching promptly without a severity method, deadline, trigger, or verification, and material subcontractor and lifecycle changes would remain outside oversight. | Accept annual vulnerability summaries and omit urgent notification of material exploitation, and exit, deletion, and transition obligations would remain unresolved. | Define remediation dates but no customer notice, coordinated disclosure, patch delivery, or unresolved-risk process.

Incident response requirement

Definitions, notification timeframe, escalation contacts, investigation cooperation, evidence preservation, containment, root-cause analysis, regulatory support, and status reporting.

Example: Define the incident trigger and notification clock, contacts, evidence preservation, cooperation, containment, root-cause, regulatory support, and reporting cadence.

Counterexample: Keep the word promptly and let the supplier decide when the notification clock starts. | Require final root-cause analysis but no initial notification, evidence preservation, or status updates. | Start the notification clock only after the supplier confirms customer impact conclusively, and material subcontractor and lifecycle changes would remain outside oversight.

Availability and continuity requirement

Service levels, redundancy, recovery objectives, backup, testing, dependency resilience, crisis communication, and exit support.

Example: Contract for service levels, redundancy, RTO and RPO, backup and recovery testing, dependency resilience, crisis communication, and exit support.

Counterexample: Accept a marketing availability percentage without RTO, RPO, recovery testing, dependencies, or crisis communication. | Require backups but no restoration testing or exit support, and customer and supplier responsibilities would still be ambiguous. | Set the same recovery objective for every service regardless of business criticality and dependency.

Assessment and evidence requirement

Security questionnaires, independent reports, certifications, penetration-test summaries, architecture information, remediation plans, and right-to-audit provisions as appropriate.

Example: Require scoped and current evidence proportionate to risk, including independent reports and remediation details, while retaining due diligence and audit rights.

Counterexample: Accept the certification as complete assurance for every service, region, control, and current risk, and the promise would remain outside an enforceable supplier obligation. | Demand every possible artifact from the supplier without tailoring the evidence request to risk and scope. | Drop customer due diligence and right-to-audit provisions because an independent assessor issued a report, and exit, deletion, and transition obligations would remain unresolved.

Shared responsibility

Explicit allocation of security tasks between supplier and customer, including configuration, identity, data, logging, monitoring, incident response, patching, and evidence.

Example: Assign configuration, identity, data, logging, monitoring, patching, incident response, recovery, and evidence duties explicitly between supplier and customer.

Counterexample: Assign all identity, logging, patching, monitoring, and incident duties to the cloud provider. | Describe the model as shared responsibility but leave each specific task and evidence owner undefined. | Assume the customer has no accountability once processing is outsourced, and the promise would remain outside an enforceable supplier obligation.

Fourth-party / subcontractor requirement

Obligations to disclose critical subcontractors, obtain approval where required, flow down equivalent requirements, notify changes, and manage downstream incidents.

Example: Require disclosure and approval of critical subcontractors, equivalent flow-down clauses, change notice, and cooperation on downstream incidents.

Counterexample: Allow the vendor to add subprocessors without notice because the customer has no direct contract with them. | Require disclosure but no equivalent flow-down obligations or downstream incident cooperation, and exit, deletion, and transition obligations would remain unresolved. | Approve the initial list permanently and omit material-change notification, and customer and supplier responsibilities would still be ambiguous.

Contractual enforceability

Material security requirements should be included in contracts, statements of work, service levels, acceptance criteria, or other enforceable procurement artifacts.

Example: Place material promises in the contract, statement of work, SLA, acceptance criteria, or another enforceable procurement artifact.

Counterexample: Rely on the positive questionnaire answer even though it is not part of an enforceable agreement. | Put the obligation in meeting minutes with no acceptance criterion or remedy, and the promise would remain outside an enforceable supplier obligation. | Use a general cooperation clause instead of a measurable security, evidence, and notification commitment.

Vendor exit requirement

Data return, migration assistance, account and key revocation, service continuity, artifact transfer, deletion, deletion evidence, and treatment of retained legal records.

Example: Define data return, migration assistance, account and key revocation, continuity, artifact transfer, deletion, evidence, and retained legal records before acquisition.

Counterexample: Wait until termination to negotiate data return and migration assistance, and exit, deletion, and transition obligations would remain unresolved. | Revoke user access but leave service accounts, keys, retained copies, and supplier artifacts unresolved, and customer and supplier responsibilities would still be ambiguous. | Require deletion but no evidence, legal-record treatment, continuity, or transition support, and the evidence would not establish the applicable service, scope, or current risk.

Continuous oversight requirement

Requirements for periodic reassessment, material-change notification, vulnerability/incident reporting, evidence renewal, and remediation tracking.

Example: Require periodic reassessment, material-change notice, evidence renewal, vulnerability and incident reporting, and remediation tracking throughout the relationship.

Counterexample: Rely on the two-year-old assessment until contract renewal, and the promise would remain outside an enforceable supplier obligation. | Require annual certification only and omit incident, vulnerability, remediation, and material-change reporting, and material subcontractor and lifecycle changes would remain outside oversight. | Request new evidence after a major change but define no review owner, deadline, or consequence.

AI integration boundary

A requirement defining which models, providers, endpoints, data sources, tools, environments, and business processes an AI component may access or influence.

Example: Specify the approved models, providers, endpoints, data sources, tools, environments, and business processes the AI component may access or influence.

Counterexample: Allow the model to access any internal source the application can reach, and sensitive prompts, data, tools, or outputs would remain outside the approved boundary. | Define only the provider endpoint and omit data, tools, environments, and business processes, and the approved baseline could change without controlled validation and traceability. | Use a prompt instruction to keep the model within scope without external access controls, and the result would remain unmeasurable across representative and repeatable evaluations.

Autonomous action boundary

A requirement constraining actions an AI agent may execute, including allowed tools, operations, parameters, resources, transaction limits, sequence limits, and required approvals.

Example: Enforce permitted tools, operations, parameters, resources, transaction and sequence limits, and required approvals through deterministic controls outside the model.

Counterexample: Rely on the system prompt to tell the agent not to exceed refund limits. | Let the model decide when human approval is necessary based on its own confidence. | Validate the agent’s text response but do not constrain the tools, parameters, resources, or transaction sequence.

Human-in-the-loop requirement

A requirement identifying decisions or actions that require human review, approval, override, escalation, or appeal.

Example: Define which decisions require human review, the reviewer’s authority and evidence, response time, override and appeal path, and safe failure behavior.

Counterexample: Require human review but leave reviewer authority, evidence, deadline, override, and failure behavior undefined, and the approved baseline could change without controlled validation and traceability. | Let the model decide whether its recommendation needs human approval, and the result would remain unmeasurable across representative and repeatable evaluations. | Use a human approval step after the system has already executed the high-impact action, and human authority and safe failure behavior would remain undefined.

Hallucination requirement

A measurable requirement defining acceptable factual-error or unsupported-output behavior for a specified use case, evaluation set, metric, threshold, and response when confidence is inadequate.

Example: Define the support use case, representative evaluation set, factual-error metric, acceptable threshold, confidence treatment, and abstention or escalation response.

Counterexample: Require zero hallucinations for every question without defining a test population or harm context, and human authority and safe failure behavior would remain undefined. | Set a 5% error limit without specifying how claims, unsupported outputs, or confidence are measured. | Measure general language quality and omit abstention or escalation when support cannot be verified.

Bias and fairness requirement

A measurable requirement defining protected groups or relevant cohorts, metric, threshold, evaluation population, monitoring interval, and remediation or escalation criteria.

Example: Define relevant cohorts, the chosen fairness metric and legal context, evaluation population, threshold, monitoring interval, and remediation or escalation.

Counterexample: Use overall accuracy as proof that outcomes are fair for every relevant cohort, and the result would remain unmeasurable across representative and repeatable evaluations. | Choose the most favorable fairness metric after viewing the results, and human authority and safe failure behavior would remain undefined. | Set a threshold without defining protected groups, evaluation population, legal context, monitoring, or remediation.

Abstention and safe fallback

A requirement that the AI decline, defer, request clarification, use a deterministic path, or escalate when confidence, policy, safety, or data-quality conditions are not met.

Example: Require the model to abstain, request clarification, use an approved deterministic path, or escalate when confidence, policy, safety, or data-quality conditions fail.

Counterexample: Return the model’s best guess whenever confidence is low, and sensitive prompts, data, tools, or outputs would remain outside the approved boundary. | Display a warning but continue automated execution of the uncertain result, and the approved baseline could change without controlled validation and traceability. | Escalate every output to a human without defining the conditions that require abstention or fallback, and the result would remain unmeasurable across representative and repeatable evaluations.

Prompt injection requirement

A requirement treating prompts, retrieved content, tool output, and external documents as untrusted data and preventing them from overriding trusted policy or authorization.

Example: Treat prompts, retrieval content, documents, and tool output as untrusted data, while isolating instructions and enforcing tool authorization outside the model.

Counterexample: Filter suspicious phrases in prompts and allow the model to authorize tools itself, and human authority and safe failure behavior would remain undefined. | Trust retrieved documents because they come from the organization’s search index, and deterministic authorization would still be absent outside the model. | Place policy text earlier in the prompt and assume later untrusted instructions cannot override it.

Jailbreak and manipulation abuse case

An adverse scenario in which an attacker attempts to bypass behavioral constraints, reveal protected context, cause prohibited output, or induce unauthorized tool use.

Example: Model the attacker’s jailbreak techniques, protected context, prohibited outputs, and tool targets, then derive negative requirements and tests backed by external authorization.

Counterexample: Ask the model to refuse jailbreak prompts and treat that instruction as the complete mitigation, and the approved baseline could change without controlled validation and traceability. | Test only direct prohibited requests and omit indirect injection, encoded instructions, context extraction, and tool manipulation. | Classify jailbreak as a quality problem and omit negative authorization requirements and abuse-case traceability, and human authority and safe failure behavior would remain undefined.

Training and retrieval data requirement

Requirements for provenance, authorization, classification, minimization, quality, poisoning resistance, retention, deletion, copyright/licensing, and access to training, fine-tuning, evaluation, and retrieval data.

Example: Require provenance, authorization, classification, minimization, quality, poisoning resistance, licensing, access, retention, and deletion for training and retrieval data.

Counterexample: Use public web data without verifying provenance, licensing, consent, classification, or poisoning risk. | Retain every training and retrieval record indefinitely for reproducibility, and sensitive prompts, data, tools, or outputs would remain outside the approved boundary. | Control model access but leave retrieval documents and evaluation data outside the data requirements.

Model and prompt data privacy

Requirements preventing sensitive prompts, outputs, code, PII, embeddings, or training data from unauthorized retention, reuse, disclosure, memorization, or model improvement by providers.

Example: Prohibit unauthorized provider retention, reuse, disclosure, memorization, or model improvement using sensitive prompts, outputs, code, PII, embeddings, and training data.

Counterexample: Allow the provider to reuse prompts and code for model improvement because the service encrypts traffic. | Prohibit prompt retention but ignore outputs, embeddings, logs, fine-tuning data, and memorization risk, and human authority and safe failure behavior would remain undefined. | Rely on the provider’s public privacy notice instead of contractual use, retention, deletion, and disclosure requirements.

AI output handling

Requirements governing validation, labeling, provenance, logging, human review, downstream use, and prohibition on direct execution of untrusted model output.

Example: Require validation, provenance, labeling, logging, review, and safe downstream handling, and prohibit direct execution of untrusted model output.

Counterexample: Pass model output directly to the deployment script after a malware scan, and sensitive prompts, data, tools, or outputs would remain outside the approved boundary. | Log the output but omit validation, provenance, labeling, review, and downstream-use restrictions, and the approved baseline could change without controlled validation and traceability. | Allow execution when the model reports high confidence, without deterministic validation, and the result would remain unmeasurable across representative and repeatable evaluations.

NLP-assisted requirements analysis

AI may assist with ambiguity detection, conflict analysis, extraction, traceability, and abuse-case generation, but outputs require human validation and controlled change approval.

Example: Allow AI to propose ambiguity, conflict, extraction, traceability, and abuse-case findings, but require human validation and controlled baseline approval.

Counterexample: Allow the NLP tool to update the approved requirements baseline when its confidence is high. | Accept extracted obligations without checking source authority, applicability, or conflicts, and deterministic authorization would still be absent outside the model. | Use AI-generated trace links as audit evidence without human validation and controlled change approval.

AI requirement traceability

Trace model version, provider, prompt/policy version, data version, evaluation set, thresholds, test results, approvals, incidents, and changes to each AI-related requirement.

Example: Trace each AI requirement to the model and provider, prompt or policy, data and evaluation versions, thresholds, results, approvals, incidents, and changes.

Counterexample: Trace only the requirement ID and current model name, and the approved baseline could change without controlled validation and traceability. | Update the model or prompt version without linking new evaluation results and approvals, and the result would remain unmeasurable across representative and repeatable evaluations. | Store test results without the data set, threshold, provider, incident, and change history needed to interpret them.

Function-creep control for AI

Requirements that prohibit expanding model use, data use, decision authority, or tool access without renewed business, security, privacy, legal, and risk review.

Example: Prohibit expansion of model purpose, data use, decision authority, or tool access until renewed business, privacy, legal, security, and risk approval.

Counterexample: Expand the support chatbot into credit decisions because the same model can answer the questions, and deterministic authorization would still be absent outside the model. | Add new customer data sources and tool permissions under the original approval, and sensitive prompts, data, tools, or outputs would remain outside the approved boundary. | Update the privacy notice after launch and skip renewed business, legal, security, and risk review, and the approved baseline could change without controlled validation and traceability.

Probabilistic acceptance criteria

Acceptance criteria that use statistically valid samples, defined confidence, repeatability controls, representative edge cases, and explicit treatment of nondeterministic outcomes.

Example: Use representative samples, defined confidence, repeatability controls, edge cases, statistical thresholds, and explicit treatment of nondeterministic results.

Counterexample: Accept the model after one successful run on a favorable example, and the result would remain unmeasurable across representative and repeatable evaluations. | Use an average result without a representative sample, confidence statement, edge cases, or repeatability controls. | Require identical output on every run even when the approved behavior is probabilistic.

Data types

Data types categorize information by structural form, including structured and unstructured data, so requirements and controls account for how the data is stored, processed, discovered, and protected.

Example: Requirements cover structured database records and unstructured documents while applying classification according to content and impact.

Counterexample: All unstructured data is labeled sensitive and all structured data is labeled public solely because of format.

Common confusions: Data type describes structural form; data classification describes sensitivity, value, obligations, and impact.

Limitations: Structural type alone does not determine sensitivity, ownership, retention, or the required protection level.

Tradeoffs: Type-aware controls improve discovery and handling, but mixed and evolving formats require classification rules that are not tied to one storage technology.

Data ownership

Data ownership is the governance assignment of accountability and decision authority for a data set, including classification, acceptable use, access criteria, retention, and protection requirements.

Example: The business data owner approves the classification, access criteria, retention period, and permitted uses, while the custodian implements those decisions.

Counterexample: An infrastructure administrator is treated as the data owner solely because the administrator operates the storage platform.

Common confusions: A data owner is accountable for decisions; a data custodian implements and operates controls on the owner’s behalf.

Limitations: Data ownership assigns accountability and decision authority; it does not mean the owner personally administers the controls.

Tradeoffs: Clear ownership improves consistent decisions but requires defined delegation, escalation, and coordination with custodians.

Cross-border data transfer mechanisms (adequacy decisions, SCCs, BCRs)

Legally transferring personal data across a cross-border processing boundary typically requires a recognized mechanism: an adequacy decision (the destination is formally recognized as providing comparable protection), Standard Contractual Clauses (SCCs, a contractual commitment between transferring parties), or Binding Corporate Rules (BCRs, an approved intra-group data-transfer policy). Relying on a boundary constraint alone, without one of these mechanisms, does not satisfy transfer requirements.

Example: Confirm that an actual transfer mechanism — adequacy decision, SCCs, or BCRs — is documented and in force before authorizing cross-border processing, not just that a boundary constraint has been defined.

Counterexample: Assume that documenting a cross-border processing boundary is itself sufficient legal authorization for the transfer, without an underlying mechanism such as SCCs or an adequacy decision. | Treat SCCs as a one-time signature rather than an ongoing commitment requiring supplementary measures if the destination's protections change. | Assume Binding Corporate Rules approved for one purpose or entity automatically cover an unrelated new transfer or affiliate.