CSSLP · Secure Software Lifecycle Management

Security integration into the development methodology

Security activities must be embedded into the organization’s development methodology, cadence, artifacts, roles, and decision points.

Example: Reassess Security integration into the development methodology using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Security integration into the development methodology only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Security integration into the development methodology changed. | Remove product-team accountability and assign all decisions about Security integration into the development methodology to a separate security function.

Limitations: Do not treat “secure SDLC” as a separate sequence that begins after functional development is complete.

Waterfall lifecycle security integration

Waterfall uses relatively sequential phases and formal phase transitions.

Example: Reassess Waterfall lifecycle security integration using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Waterfall lifecycle security integration only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Waterfall lifecycle security integration changed. | Remove product-team accountability and assign all decisions about Waterfall lifecycle security integration to a separate security function.

Limitations: Waterfall does not mean security is performed only once; changes can require re-entry into earlier analysis and approval activities.

Agile lifecycle security integration

Agile delivers value iteratively.

Example: Reassess Agile lifecycle security integration using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Agile lifecycle security integration only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Agile lifecycle security integration changed. | Remove product-team accountability and assign all decisions about Agile lifecycle security integration to a separate security function.

Limitations: Agile does not remove documentation, governance, or approval requirements; it changes their timing and form.

DevOps and DevSecOps lifecycle management

DevOps integrates development and operations through collaboration, automation, and rapid feedback.

Example: Reassess DevOps and DevSecOps lifecycle management using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address DevOps and DevSecOps lifecycle management only at the final release review. | Reuse the previous approval even though requirements or architecture affecting DevOps and DevSecOps lifecycle management changed. | Remove product-team accountability and assign all decisions about DevOps and DevSecOps lifecycle management to a separate security function.

Limitations: DevSecOps is not synonymous with adding scanning tools.

Tradeoffs: Pipeline hardening and release execution are emphasized in Domain 7; Domain 2 establishes the lifecycle governance and management model.

Iterative and incremental risk treatment

Incremental delivery requires repeated risk assessment.

Example: Reassess Iterative and incremental risk treatment using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Iterative and incremental risk treatment only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Iterative and incremental risk treatment changed. | Remove product-team accountability and assign all decisions about Iterative and incremental risk treatment to a separate security function.

Limitations: Do not assume a security review performed for an earlier increment automatically covers later increments.

Security activities scaled to risk

Security rigor should be proportional to data sensitivity, business criticality, exposure, legal obligations, architecture, threat likelihood, and potential impact.

Example: Reassess Security activities scaled to risk using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Security activities scaled to risk only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Security activities scaled to risk changed. | Remove product-team accountability and assign all decisions about Security activities scaled to risk to a separate security function.

Limitations: Risk-based tailoring does not justify silently omitting mandatory regulatory or contractual controls.

Security roles and shared accountability

Lifecycle security requires clear responsibility across executives, product owners, developers, architects, testers, operations, legal/privacy, risk, security champions, and independent assessors.

Example: Reassess Security roles and shared accountability using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Security roles and shared accountability only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Security roles and shared accountability changed. | Remove product-team accountability and assign all decisions about Security roles and shared accountability to a separate security function.

Limitations: “Security is everyone’s responsibility” must not be used to eliminate a specifically accountable owner.

Security champions

A security champion is a development or product-team member who helps integrate security practices, provides local guidance, and connects the team with security specialists.

Example: Reassess Security champions using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Security champions only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Security champions changed. | Remove product-team accountability and assign all decisions about Security champions to a separate security function.

Limitations: A security champion supports adoption but does not automatically replace qualified security architects, assessors, or risk owners.

Definition of Ready and Definition of Done

Definition of Ready can require adequate security context before work begins.

Example: Reassess Definition of Ready and Definition of Done using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Definition of Ready and Definition of Done only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Definition of Ready and Definition of Done changed. | Remove product-team accountability and assign all decisions about Definition of Ready and Definition of Done to a separate security function.

Limitations: A story being functionally complete does not make it security-complete when security acceptance criteria remain unmet.

Security debt

Security debt is the accumulated future cost and risk created by deferred security work, temporary exceptions, obsolete controls, or insecure design shortcuts.

Example: Record the debt with a risk owner, priority, compensating controls, remediation date, and review trigger.

Counterexample: Add the deferred work to the ordinary backlog without a risk owner or expiration date. | Treat product-owner agreement as formal residual-risk acceptance. | Close the debt when a later scan reports no new findings, without addressing the deferred design weakness.

Limitations: Security debt is not eliminated by renaming vulnerabilities as backlog items without risk ownership and remediation commitments.

Tailoring versus waiving

Tailoring adjusts practices to context while preserving objectives and documenting rationale.

Example: Reassess Tailoring versus waiving using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Tailoring versus waiving only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Tailoring versus waiving changed. | Remove product-team accountability and assign all decisions about Tailoring versus waiving to a separate security function.

Limitations: Do not describe an undocumented omission as risk-based tailoring.

Continuous feedback and improvement

Findings from testing, incidents, operations, metrics, audits, and user feedback should update standards, training, roadmaps, backlog priorities, and lifecycle controls.

Example: Reassess Continuous feedback and improvement using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Continuous feedback and improvement only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Continuous feedback and improvement changed. | Remove product-team accountability and assign all decisions about Continuous feedback and improvement to a separate security function.

Tradeoffs: Domain 7 executes monitoring and incident response; Domain 2 ensures feedback is incorporated into lifecycle governance.

Economics of early security integration

Finding and resolving security weaknesses earlier in the lifecycle generally reduces downstream rework, architectural disruption, emergency release effort, operational exposure, and incident-related cost.

Example: Reassess Economics of early security integration using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Economics of early security integration only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Economics of early security integration changed. | Remove product-team accountability and assign all decisions about Economics of early security integration to a separate security function.

Limitations: Do not state that production remediation is always a specific number of times more expensive unless a named study or scenario supplies that figure.

Tradeoffs: Domain 2 governs when security activities occur; Domains 3–6 define and execute requirements, design, implementation, and testing work.

Shift-left scope and limitations

Shift left means moving appropriate security decisions and feedback earlier, including risk analysis, security requirements, threat-informed design review, developer enablement, secure standards, and early automated checks.

Example: Keep the early analysis and retain production monitoring, incident learning, and operational validation.

Counterexample: Have the security team address Shift-left scope and limitations only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Shift-left scope and limitations changed. | Remove product-team accountability and assign all decisions about Shift-left scope and limitations to a separate security function.

Limitations: Do not equate shift left solely with running SAST earlier.

Secure-by-design and privacy-by-design lifecycle governance

Lifecycle governance should require security and privacy considerations from project initiation through retirement.

Example: Reassess Secure-by-design and privacy-by-design lifecycle governance using current risk, accountable roles, updated artifacts, and evidence appropriate to the development method.

Counterexample: Have the security team address Secure-by-design and privacy-by-design lifecycle governance only at the final release review. | Reuse the previous approval even though requirements or architecture affecting Secure-by-design and privacy-by-design lifecycle governance changed. | Remove product-team accountability and assign all decisions about Secure-by-design and privacy-by-design lifecycle governance to a separate security function.

Limitations: Secure by design and privacy by design are related but not interchangeable.

Tradeoffs: Domain 2 integrates these practices into governance and gates; Domain 3 defines resulting requirements; Domain 4 selects architecture and design controls.

Identify and adopt security standards

Organizations identify applicable external and internal standards, evaluate their relevance, formally adopt selected practices, tailor them where permitted, and integrate them into lifecycle processes and evidence requirements.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Identify and adopt security standards.

Counterexample: Allow each team to select its own version and scope for Identify and adopt security standards. | Treat publication of Identify and adopt security standards as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Implementing security frameworks

A framework provides organized practices, control objectives, maturity guidance, or lifecycle activities.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Implementing security frameworks.

Counterexample: Allow each team to select its own version and scope for Implementing security frameworks. | Treat publication of Implementing security frameworks as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: Naming a framework is not implementation.

Promoting security awareness

Security awareness helps stakeholders understand why lifecycle controls exist, how individual behavior affects risk, and when to escalate concerns.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Promoting security awareness.

Counterexample: Allow each team to select its own version and scope for Promoting security awareness. | Treat publication of Promoting security awareness as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: Awareness is not the same as role-specific skills training or demonstrated competence.

Policy, standard, procedure, and guideline hierarchy

Policies state management intent; standards define mandatory requirements; procedures specify repeatable steps; guidelines provide recommended practices.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Policy, standard, procedure, and guideline hierarchy.

Counterexample: Allow each team to select its own version and scope for Policy, standard, procedure, and guideline hierarchy. | Treat publication of Policy, standard, procedure, and guideline hierarchy as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: Do not treat a voluntary guideline as equivalent to a mandatory organizational standard unless formally adopted as such.

External versus internal standards

External sources include laws, industry standards, and recognized frameworks.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for External versus internal standards.

Counterexample: Allow each team to select its own version and scope for External versus internal standards. | Treat publication of External versus internal standards as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Standards applicability, scoping, and gap analysis

Applicability analysis determines whether a source applies; scoping defines the systems, data, environments, organizational units, and clauses in scope; gap analysis compares current practices and evidence with applicable requirements.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Standards applicability, scoping, and gap analysis.

Counterexample: Allow each team to select its own version and scope for Standards applicability, scoping, and gap analysis. | Treat publication of Standards applicability, scoping, and gap analysis as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Standards mapping and control crosswalks

A crosswalk maps requirements or practices among multiple standards to reduce duplication and identify gaps.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Standards mapping and control crosswalks.

Counterexample: Allow each team to select its own version and scope for Standards mapping and control crosswalks. | Treat publication of Standards mapping and control crosswalks as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: Similar control wording across frameworks does not guarantee identical scope, rigor, or evidence requirements.

Secure development standards

Secure development standards may define required lifecycle practices, approved tools, coding rules, review requirements, vulnerability thresholds, and exception processes.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Secure development standards.

Counterexample: Allow each team to select its own version and scope for Secure development standards. | Treat publication of Secure development standards as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

NIST Secure Software Development Framework

NIST SP 800-218 organizes secure software development practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for NIST Secure Software Development Framework.

Counterexample: Allow each team to select its own version and scope for NIST Secure Software Development Framework. | Treat publication of NIST Secure Software Development Framework as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: SSDF does not prescribe one development methodology or one toolchain.

OWASP SAMM and maturity-based improvement

OWASP SAMM supports assessment and improvement of software assurance practices through a maturity model.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for OWASP SAMM and maturity-based improvement.

Counterexample: Allow each team to select its own version and scope for OWASP SAMM and maturity-based improvement. | Treat publication of OWASP SAMM and maturity-based improvement as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: A higher maturity score does not prove that a particular application is vulnerability-free.

BSIMM as an observational model

BSIMM describes observed software security initiatives and can support benchmarking and program planning.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for BSIMM as an observational model.

Counterexample: Allow each team to select its own version and scope for BSIMM as an observational model. | Treat publication of BSIMM as an observational model as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: Do not present BSIMM as a certification standard or mandatory sequence of controls.

SAFECode practices

SAFECode publishes industry practices for secure software development and can inform lifecycle standards, training, and governance.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for SAFECode practices.

Counterexample: Allow each team to select its own version and scope. | Treat publication of SAFECode practices as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: The outline lists SAFECode as an example source; it does not make every SAFECode publication mandatory.

Standards lifecycle and maintenance

Adopted standards must be versioned, owned, reviewed, updated for emerging threats and technology, communicated, and linked to exception and migration processes.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Standards lifecycle and maintenance.

Counterexample: Allow each team to select its own version and scope for Standards lifecycle and maintenance. | Treat publication of Standards lifecycle and maintenance as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: A standard that is never reviewed can become a source of risk through obsolete controls or unsupported technologies.

Role-based security training

Role-specific training addresses the knowledge and skills needed by developers, testers, architects, product owners, operations staff, and managers.

Example: Define applicability, approved version, internal mapping, accountable roles, required evidence, and maintenance for Role-based security training.

Counterexample: Allow each team to select its own version and scope for Role-based security training. | Treat publication of Role-based security training as proof that mapped practices and evidence exist. | Freeze the adopted version even after technology, obligations, or threats materially change.

Limitations: Completion rates measure participation, not necessarily competence or behavior change.

Security strategy and roadmap

A strategy defines direction, desired outcomes, principles, and alignment with business objectives.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Security strategy and roadmap.

Counterexample: Keep the original roadmap sequence for Security strategy and roadmap after dependencies and funding assumptions change. | Prioritize the easiest activity related to Security strategy and roadmap rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Limitations: A roadmap is not merely a list of tools to purchase.

Current-state and target-state assessment

Roadmap development begins by understanding current capabilities, weaknesses, risk exposure, business constraints, and the desired future state.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Current-state and target-state assessment.

Counterexample: Keep the original roadmap sequence for Current-state and target-state assessment after dependencies and funding assumptions change. | Prioritize the easiest activity related to Current-state and target-state assessment rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Gap analysis

Gap analysis compares current practices and evidence against target requirements or maturity objectives.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Gap analysis.

Counterexample: Keep the original roadmap sequence for Gap analysis after dependencies and funding assumptions change. | Prioritize the easiest activity related to Gap analysis rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Security milestones and checkpoints

Milestones and checkpoints establish when security evidence is reviewed and decisions are made across the lifecycle.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Security milestones and checkpoints.

Counterexample: Keep the original roadmap sequence for Security milestones and checkpoints after dependencies and funding assumptions change. | Prioritize the easiest activity related to Security milestones and checkpoints rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Limitations: A checkpoint should have defined criteria, decision authority, evidence, and an exception path.

Formal lifecycle reviews such as PDR and CDR

Preliminary Design Review (PDR) and Critical Design Review (CDR) are formal systems-engineering review examples that can serve as lifecycle checkpoints.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Formal lifecycle reviews such as PDR and CDR.

Counterexample: Keep the original roadmap sequence for Formal lifecycle reviews such as PDR and CDR after dependencies and funding assumptions change. | Prioritize the easiest activity related to Formal lifecycle reviews such as PDR and CDR rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Limitations: Do not imply that every project or methodology must use PDR/CDR, or that these reviews are exclusively security reviews.

Tradeoffs: Domain 2 governs review timing, entry and exit criteria, evidence, participation, and decision authority.

Control gates

A control gate is a formal decision point that determines whether work may proceed, must be remediated, requires an exception, or must stop.

Example: Apply defined risk-based criteria, verified evidence, accountable approval, and a controlled exception path.

Counterexample: Keep the original roadmap sequence for Control gates after dependencies and funding assumptions change. | Prioritize the easiest activity related to Control gates rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Break/build criteria

Break/build criteria define conditions that block or permit progression, build completion, release, or deployment.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Break/build criteria.

Counterexample: Keep the original roadmap sequence for Break/build criteria after dependencies and funding assumptions change. | Prioritize the easiest activity related to Break/build criteria rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Limitations: A single vulnerability count is usually insufficient without severity, exploitability, exposure, and business context.

Risk-based prioritization of initiatives

Roadmaps should prioritize initiatives that reduce material risk, satisfy mandatory obligations, unlock dependencies, or create reusable capabilities.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Risk-based prioritization of initiatives.

Counterexample: Keep the original roadmap sequence for Risk-based prioritization of initiatives after dependencies and funding assumptions change. | Prioritize the easiest activity related to Risk-based prioritization of initiatives rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Quick wins and foundational capabilities

Quick wins build momentum, but foundational capabilities such as asset inventory, ownership, standards, training, pipeline controls, and reporting may be prerequisites for sustainable improvement.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Quick wins and foundational capabilities.

Counterexample: Keep the original roadmap sequence for Quick wins and foundational capabilities after dependencies and funding assumptions change. | Prioritize the easiest activity related to Quick wins and foundational capabilities rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Roadmap dependencies

Dependencies may include staffing, tooling, architecture modernization, data classification, identity services, procurement, supplier cooperation, and policy approval.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Roadmap dependencies.

Counterexample: Keep the original roadmap sequence for Roadmap dependencies after dependencies and funding assumptions change. | Prioritize the easiest activity related to Roadmap dependencies rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Roadmap governance and review

Roadmaps require ownership, funding, progress measures, periodic review, reprioritization, and explicit handling of delayed or cancelled initiatives.

Example: Reassess risk, dependencies, owners, decision criteria, milestones, and sequencing before updating Roadmap governance and review.

Counterexample: Keep the original roadmap sequence for Roadmap governance and review after dependencies and funding assumptions change. | Prioritize the easiest activity related to Roadmap governance and review rather than the highest material risk. | Replace the roadmap milestone with a tool purchase that has no owner, operating target, or exit criterion.

Post-quantum cryptography roadmap

The current ISC2 AI integration narrative cites strategic roadmaps for post-quantum cryptography as an example of lifecycle planning for future risk.

Example: Inventory dependencies, build crypto-agility, define migration triggers, test transitions, and govern phased adoption.

Counterexample: Replace every cryptographic algorithm immediately, even where standards and interoperability are not ready. | Delay all migration planning until current algorithms are formally prohibited. | Purchase a scanning tool and treat the procurement as completion of the migration roadmap.

Limitations: Do not imply that every application must immediately replace current cryptography without risk, standards, and migration analysis.

Define and develop security documentation

Security documentation records decisions, requirements, responsibilities, processes, evidence, exceptions, and operational knowledge needed to manage software risk throughout the lifecycle.

Example: Update, review, approve, version, protect, and distribute the documentation for Define and develop security documentation to the audiences that use it.

Counterexample: Keep the obsolete Define and develop security documentation document because it demonstrates historical compliance. | Allow uncontrolled edits to the Define and develop security documentation documentation so updates can be made quickly. | Use the same Define and develop security documentation document for executives, engineers, operators, and assessors despite different needs.

Documentation purpose and audience

Documents should be appropriate for their users: executives need risk and decision information; practitioners need actionable standards and procedures; assessors need traceable evidence; operators need runbooks.

Example: Update, review, approve, version, protect, and distribute the documentation for Documentation purpose and audience to the audiences that use it.

Counterexample: Keep the obsolete Documentation purpose and audience document because it demonstrates historical compliance. | Allow uncontrolled edits to the Documentation purpose and audience documentation so updates can be made quickly. | Use the same Documentation purpose and audience document for executives, engineers, operators, and assessors despite different needs.

Security plan

A security plan describes scope, objectives, responsibilities, applicable requirements, planned controls, assurance activities, milestones, and reporting expectations.

Example: Update, review, approve, version, protect, and distribute the documentation for Security plan to the audiences that use it.

Counterexample: Keep the obsolete Security plan document because it demonstrates historical compliance. | Allow uncontrolled edits to the Security plan documentation so updates can be made quickly. | Use the same Security plan document for executives, engineers, operators, and assessors despite different needs.

Policies, standards, procedures, and guidelines

The documentation set should preserve the hierarchy between management direction, mandatory rules, repeatable steps, and recommendations.

Example: Update, review, approve, version, protect, and distribute the documentation for Policies, standards, procedures, and guidelines to the audiences that use it.

Counterexample: Keep the obsolete Policies, standards, procedures, and guidelines document because it demonstrates historical compliance. | Allow uncontrolled edits to the Policies, standards, procedures, and guidelines documentation so updates can be made quickly. | Use the same Policies, standards, procedures, and guidelines document for executives, engineers, operators, and assessors despite different needs.

Operational runbooks and playbooks

Runbooks describe routine operational procedures; playbooks coordinate response to defined events or scenarios.

Example: Update, review, approve, version, protect, and distribute the documentation for Operational runbooks and playbooks to the audiences that use it.

Counterexample: Keep the obsolete Operational runbooks and playbooks document because it demonstrates historical compliance. | Allow uncontrolled edits to the Operational runbooks and playbooks documentation so updates can be made quickly. | Use the same Operational runbooks and playbooks document for executives, engineers, operators, and assessors despite different needs.

Tradeoffs: Domain 7 executes operational and incident-response procedures.

Exception and risk-acceptance records

An exception record should identify the unmet requirement, rationale, affected scope, compensating controls, residual risk, approver, owner, expiration, and review conditions.

Example: Update, review, approve, version, protect, and distribute the documentation for Exception and risk-acceptance records to the audiences that use it.

Counterexample: Keep the obsolete Exception and risk-acceptance records document because it demonstrates historical compliance. | Allow uncontrolled edits to the Exception and risk-acceptance records documentation so updates can be made quickly. | Use the same Exception and risk-acceptance records document for executives, engineers, operators, and assessors despite different needs.

Limitations: An open-ended exception without accountable risk acceptance is not adequate governance.

Documentation configuration control

Security documents should have owners, version control, approval status, effective dates, change history, access restrictions, and retention rules.

Example: Update, review, approve, version, protect, and distribute the documentation for Documentation configuration control to the audiences that use it.

Counterexample: Keep the obsolete Documentation configuration control document because it demonstrates historical compliance. | Allow uncontrolled edits to the Documentation configuration control documentation so updates can be made quickly. | Use the same Documentation configuration control document for executives, engineers, operators, and assessors despite different needs.

Living documentation

Documentation should be updated when systems, threats, controls, dependencies, regulations, or operating assumptions change.

Example: Update, review, approve, version, protect, and distribute the documentation for Living documentation to the audiences that use it.

Counterexample: Keep the obsolete Living documentation document because it demonstrates historical compliance. | Allow uncontrolled edits to the Living documentation documentation so updates can be made quickly. | Use the same Living documentation document for executives, engineers, operators, and assessors despite different needs.

Limitations: “Living documentation” does not mean unapproved or uncontrolled documentation.

Documentation classification and protection

Security documents may contain architecture details, credentials locations, vulnerabilities, incident procedures, or supplier information and therefore require appropriate classification and access control.

Example: Update, review, approve, version, protect, and distribute the documentation for Documentation classification and protection to the audiences that use it.

Counterexample: Keep the obsolete Documentation classification and protection document because it demonstrates historical compliance. | Allow uncontrolled edits to the Documentation classification and protection documentation so updates can be made quickly. | Use the same Documentation classification and protection document for executives, engineers, operators, and assessors despite different needs.

Documentation quality criteria

Useful security documentation is accurate, complete enough for purpose, consistent, understandable, traceable, approved, current, and retrievable.

Example: Update, review, approve, version, protect, and distribute the documentation for Documentation quality criteria to the audiences that use it.

Counterexample: Keep the obsolete Documentation quality criteria document because it demonstrates historical compliance. | Allow uncontrolled edits to the Documentation quality criteria documentation so updates can be made quickly. | Use the same Documentation quality criteria document for executives, engineers, operators, and assessors despite different needs.

Define security metrics

Security metrics quantify the condition, performance, efficiency, effectiveness, risk, or outcome of lifecycle security activities.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Define security metrics to action thresholds.

Counterexample: Compare raw Define security metrics values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Define security metrics alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Define security metrics number without validating whether risk or exposure decreased.

Criticality level

Criticality expresses the importance of an application, component, service, or finding based on business impact, safety, data sensitivity, dependencies, exposure, and recovery needs.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Criticality level to action thresholds.

Counterexample: Compare raw Criticality level values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Criticality level alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Criticality level number without validating whether risk or exposure decreased.

Limitations: Criticality is not identical to vulnerability severity.

Average remediation time

Average remediation time measures the elapsed time from a defined starting event to verified remediation.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Average remediation time to action thresholds.

Counterexample: Compare raw Average remediation time values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Average remediation time alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Average remediation time number without validating whether risk or exposure decreased.

Limitations: Averages can conceal overdue high-risk items; use distributions, percentiles, or SLA compliance where appropriate.

Complexity as a metric

Complexity may refer to code, architecture, dependency, process, or remediation complexity.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Complexity as a metric to action thresholds.

Counterexample: Compare raw Complexity as a metric values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Complexity as a metric alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Complexity as a metric number without validating whether risk or exposure decreased.

Key Performance Indicators

KPIs measure performance against important objectives, such as remediation compliance, security-review completion, or gate pass rates.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Key Performance Indicators to action thresholds.

Counterexample: Compare raw Key Performance Indicators values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Key Performance Indicators alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Key Performance Indicators number without validating whether risk or exposure decreased.

Objectives and Key Results

OKRs pair a qualitative objective with measurable key results.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Objectives and Key Results to action thresholds.

Counterexample: Compare raw Objectives and Key Results values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Objectives and Key Results alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Objectives and Key Results number without validating whether risk or exposure decreased.

KPI versus KRI

A KPI measures performance toward an objective.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link KPI versus KRI to action thresholds.

Counterexample: Compare raw KPI versus KRI values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for KPI versus KRI alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the KPI versus KRI number without validating whether risk or exposure decreased.

Leading and lagging indicators

Leading indicators suggest future performance or risk, such as training competence or unresolved design risks.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Leading and lagging indicators to action thresholds.

Counterexample: Compare raw Leading and lagging indicators values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Leading and lagging indicators alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Leading and lagging indicators number without validating whether risk or exposure decreased.

Activity, output, outcome, and impact metrics

Activity metrics count work performed; output metrics describe delivered artifacts; outcome metrics measure changed behavior or risk; impact metrics connect security improvement to business consequences.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Activity, output, outcome, and impact metrics to action thresholds.

Counterexample: Compare raw Activity, output, outcome, and impact metrics values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Activity, output, outcome, and impact metrics alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Activity, output, outcome, and impact metrics number without validating whether risk or exposure decreased.

Limitations: More scans, reviews, or training hours do not necessarily mean lower risk.

Metric validity and reliability

A valid metric measures the intended concept.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Metric validity and reliability to action thresholds.

Counterexample: Compare raw Metric validity and reliability values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Metric validity and reliability alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Metric validity and reliability number without validating whether risk or exposure decreased.

Metric normalization and context

Raw counts should often be normalized by application size, release frequency, user population, exposure, or criticality to support meaningful comparison.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Metric normalization and context to action thresholds.

Counterexample: Compare raw Metric normalization and context values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Metric normalization and context alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Metric normalization and context number without validating whether risk or exposure decreased.

Metric gaming and Goodhart’s law

When a measure becomes a target, teams may optimize the number rather than the security outcome.

Example: Use balanced outcome and risk measures, review gaming behavior, and verify that exposure actually decreases.

Counterexample: Raise the closure target so teams process more tickets. | Replace the count with one unsegmented average across all severities and products. | Stop measuring remediation entirely because any target can be gamed.

Mean time to detect, remediate, and recover

Time-based metrics require clear event definitions and should be segmented by severity and system criticality.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Mean time to detect, remediate, and recover to action thresholds.

Counterexample: Compare raw Mean time to detect, remediate, and recover values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Mean time to detect, remediate, and recover alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Mean time to detect, remediate, and recover number without validating whether risk or exposure decreased.

Vulnerability escape rate

Escape rate measures security defects discovered after an intended detection stage, such as after release.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Vulnerability escape rate to action thresholds.

Counterexample: Compare raw Vulnerability escape rate values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Vulnerability escape rate alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Vulnerability escape rate number without validating whether risk or exposure decreased.

False-positive and false-negative rates

Tool and process quality should consider both false positives, which consume effort, and false negatives, which leave risk undetected.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link False-positive and false-negative rates to action thresholds.

Counterexample: Compare raw False-positive and false-negative rates values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for False-positive and false-negative rates alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the False-positive and false-negative rates number without validating whether risk or exposure decreased.

Coverage metrics

Coverage may measure applications, components, requirements, threat scenarios, code, or controls assessed.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Coverage metrics to action thresholds.

Counterexample: Compare raw Coverage metrics values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Coverage metrics alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Coverage metrics number without validating whether risk or exposure decreased.

Security maturity metrics

Maturity metrics track the institutionalization and consistency of practices.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Security maturity metrics to action thresholds.

Counterexample: Compare raw Security maturity metrics values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Security maturity metrics alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Security maturity metrics number without validating whether risk or exposure decreased.

Metric ownership and action thresholds

Each important metric should have an owner, calculation method, source, frequency, audience, threshold, and defined response when thresholds are exceeded.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Metric ownership and action thresholds to action thresholds.

Counterexample: Compare raw Metric ownership and action thresholds values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Metric ownership and action thresholds alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Metric ownership and action thresholds number without validating whether risk or exposure decreased.

Return on Security Investment

Return on Security Investment (ROSI) supports comparison and business justification by relating expected loss reduction to the full cost of a security investment.

Example: Define the calculation and data source, normalize or segment results, validate the measure, and link Return on Security Investment to action thresholds.

Counterexample: Compare raw Return on Security Investment values across products without accounting for size, criticality, exposure, or release frequency. | Use the average for Return on Security Investment alone and omit aging, percentiles, and severe outliers. | Reward teams for improving the Return on Security Investment number without validating whether risk or exposure decreased.

Limitations: Do not use ROSI as the sole decision criterion.

Application decommissioning

Decommissioning is a planned lifecycle activity that retires software, services, infrastructure, credentials, data, integrations, licenses, and support obligations without leaving unmanaged risk.

Example: Complete Application decommissioning across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Application decommissioning when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Application decommissioning closure review. | Leave unresolved Application decommissioning items undocumented to leave them available during later troubleshooting activities.

End-of-Life policy

An EOL policy defines triggers, responsibilities, notification, transition, retention, shutdown, evidence, and approval for retiring applications.

Example: Complete End-of-Life policy across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close End-of-Life policy when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the End-of-Life policy closure review. | Leave unresolved End-of-Life policy items undocumented to leave them available during later troubleshooting activities.

Credential removal

Remove or revoke user, service, API, database, cloud, certificate, token, and privileged credentials associated with the retired application.

Example: Inventory and revoke all associated human and nonhuman credentials, certificates, tokens, sessions, and privileged access.

Counterexample: Disable only interactive user accounts and leave service accounts, tokens, certificates, and active sessions unchanged. | Wait for machine credentials to expire naturally after the application is retired. | Archive the credential inventory for troubleshooting while keeping the credentials active.

Limitations: Disabling a user interface does not revoke back-end credentials or active tokens.

Configuration removal

Remove obsolete configuration, DNS records, firewall rules, routes, scheduled jobs, secrets, deployment definitions, and trust relationships.

Example: Complete Configuration removal across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Configuration removal when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Configuration removal closure review. | Leave unresolved Configuration removal items undocumented to leave them available during later troubleshooting activities.

License cancellation

Cancel or reallocate licenses and subscriptions while preserving records needed for audit, contractual, or legal purposes.

Example: Complete License cancellation across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close License cancellation when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the License cancellation closure review. | Leave unresolved License cancellation items undocumented to leave them available during later troubleshooting activities.

Archiving

Archive required application data, records, documentation, source, binaries, configurations, and evidence in a protected, retrievable, and interpretable form.

Example: Complete Archiving across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Archiving when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Archiving closure review. | Leave unresolved Archiving items undocumented to leave them available during later troubleshooting activities.

Limitations: Archiving is not the same as leaving a production system running indefinitely.

Service-level agreement closure

Update or terminate SLAs, support agreements, monitoring commitments, and escalation arrangements associated with the retired service.

Example: Complete Service-level agreement closure across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Service-level agreement closure when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Service-level agreement closure closure review. | Leave unresolved Service-level agreement closure items undocumented to leave them available during later troubleshooting activities.

Data disposition

Data disposition determines what data is retained, transferred, archived, anonymized, or destroyed, by whom, when, and with what evidence.

Example: Complete Data disposition across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Data disposition when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Data disposition closure review. | Leave unresolved Data disposition items undocumented to leave them available during later troubleshooting activities.

Retention during decommissioning

Retention decisions must account for legal, regulatory, contractual, business, litigation-hold, privacy, and operational requirements.

Example: Complete Retention during decommissioning across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Retention during decommissioning when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Retention during decommissioning closure review. | Leave unresolved Retention during decommissioning items undocumented to leave them available during later troubleshooting activities.

Secure destruction

Destruction should be appropriate to media, data sensitivity, technology, replication, backups, and assurance requirements.

Example: Complete Secure destruction across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Secure destruction when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Secure destruction closure review. | Leave unresolved Secure destruction items undocumented to leave them available during later troubleshooting activities.

Dependency analysis

Identify upstream and downstream systems, users, interfaces, data consumers, shared services, batch jobs, monitoring, suppliers, and operational processes before shutdown.

Example: Complete Dependency analysis across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Dependency analysis when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Dependency analysis closure review. | Leave unresolved Dependency analysis items undocumented to leave them available during later troubleshooting activities.

Limitations: An application with no direct users may still be a critical dependency.

Migration and transition planning

Where services or data move to a replacement, define integrity validation, security-equivalence criteria, rollback, user communication, cutover, and post-migration verification.

Example: Complete Migration and transition planning across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Migration and transition planning when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Migration and transition planning closure review. | Leave unresolved Migration and transition planning items undocumented to leave them available during later troubleshooting activities.

Residual attack-surface removal

Remove internet endpoints, dormant hosts, repositories, packages, images, keys, accounts, and monitoring exceptions that could remain exploitable after retirement.

Example: Complete Residual attack-surface removal across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Residual attack-surface removal when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Residual attack-surface removal closure review. | Leave unresolved Residual attack-surface removal items undocumented to leave them available during later troubleshooting activities.

Decommission approval and evidence

Closure should be approved by accountable owners and supported by evidence that dependencies, data, credentials, configurations, contracts, and records were handled.

Example: Complete Decommission approval and evidence across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Decommission approval and evidence when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Decommission approval and evidence closure review. | Leave unresolved Decommission approval and evidence items undocumented to leave them available during later troubleshooting activities.

Data remanence

Data remanence is residual data that remains after nominal deletion or media reuse.

Example: Complete Data remanence across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Data remanence when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Data remanence closure review. | Leave unresolved Data remanence items undocumented to leave them available during later troubleshooting activities.

Backup and replicated-copy disposition

Decommission plans should address backups, replicas, caches, archives, disaster-recovery environments, and third-party copies.

Example: Complete Backup and replicated-copy disposition across production, backups, replicas, integrations, credentials, obligations, approvals, and retained evidence.

Counterexample: Close Backup and replicated-copy disposition when the user-facing service is disabled, even though dependent services or stored copies remain. | Exclude backups, replicas, caches, archives, and third-party copies from the Backup and replicated-copy disposition closure review. | Leave unresolved Backup and replicated-copy disposition items undocumented to leave them available during later troubleshooting activities.

Limitations: Deleting the primary database does not establish that all copies have been disposed of.

Cryptographic erase

Cryptographic erase renders encrypted target data infeasible to recover by securely sanitizing the cryptographic keys required to decrypt it.

Example: Confirm all relevant copies use controlled keys, destroy every applicable key copy, and separately handle plaintext exports, caches, and replicas.

Counterexample: Destroy the production key but retain escrowed and backup key copies indefinitely. | Assume encrypted storage proves that no plaintext exports, caches, or replicas exist. | Erase the primary volume and leave replicated data encrypted under still-active keys.

Limitations: Deleting a key does not prove destruction of unencrypted copies, caches, logs, exports, snapshots, or independently encrypted replicas.

Security reporting mechanisms

Reporting mechanisms communicate security posture, performance, risk, exceptions, trends, and decisions to appropriate audiences with defined cadence and escalation.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Security reporting mechanisms.

Counterexample: Publish one Security reporting mechanisms summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Security reporting mechanisms when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Security reporting mechanisms escalation until the next scheduled dashboard publication.

Security reports

Reports may provide detailed findings, risk analysis, status, ownership, aging, remediation commitments, and evidence for operational or governance audiences.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Security reports.

Counterexample: Publish one Security reports summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Security reports when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Security reports escalation until the next scheduled dashboard publication.

Security dashboards

Dashboards provide concise, frequently updated views of selected metrics, thresholds, trends, and exceptions.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Security dashboards.

Counterexample: Publish one Security dashboards summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Security dashboards when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Security dashboards escalation until the next scheduled dashboard publication.

Limitations: A visually attractive dashboard is not useful if definitions, data quality, and response ownership are unclear.

Feedback loops

Feedback loops route findings and outcomes back into standards, training, requirements, architecture, backlog, gates, and roadmap priorities.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Feedback loops.

Counterexample: Publish one Feedback loops summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Feedback loops when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Feedback loops escalation until the next scheduled dashboard publication.

Audience-specific reporting

Executives need business risk and decisions; product teams need actionable findings; security leaders need trends and control effectiveness; auditors need traceability and evidence.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Audience-specific reporting.

Counterexample: Publish one Audience-specific reporting summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Audience-specific reporting when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Audience-specific reporting escalation until the next scheduled dashboard publication.

Reporting cadence

Cadence should reflect decision speed, risk volatility, regulatory obligations, and audience needs.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Reporting cadence.

Counterexample: Publish one Reporting cadence summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Reporting cadence when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Reporting cadence escalation until the next scheduled dashboard publication.

Traffic-light and threshold reporting

Red/amber/green indicators require explicit thresholds, context, trend, and action definitions.

Example: Use defined thresholds, aging, exploitability, uncertainty, trend, and escalation criteria.

Counterexample: Keep the dashboard green because no finding is currently classified as critical. | Mark every overdue finding red without considering exploitability, business impact, or uncertainty. | Remove thresholds and trends and report only the total number of findings.

Limitations: Color alone can hide uncertainty or create false confidence.

Drill-down and traceability

Aggregated reports should allow authorized users to trace material indicators to underlying applications, findings, evidence, owners, and decisions.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Drill-down and traceability.

Counterexample: Publish one Drill-down and traceability summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Drill-down and traceability when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Drill-down and traceability escalation until the next scheduled dashboard publication.

Data quality in reporting

Reporting data should be complete enough, timely, consistently classified, deduplicated, and protected from unauthorized modification.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Data quality in reporting.

Counterexample: Publish one Data quality in reporting summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Data quality in reporting when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Data quality in reporting escalation until the next scheduled dashboard publication.

Automated ticketing and workflow integration

The current ISC2 AI integration narrative includes automated security ticketing.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Automated ticketing and workflow integration.

Counterexample: Publish one Automated ticketing and workflow integration summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Automated ticketing and workflow integration when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Automated ticketing and workflow integration escalation until the next scheduled dashboard publication.

Limitations: Automated ticket creation is not equivalent to validated remediation or risk closure.

Reporting exceptions and residual risk

Reports should distinguish open findings, accepted risks, temporary exceptions, false positives, disputed findings, and completed remediation.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Reporting exceptions and residual risk.

Counterexample: Publish one Reporting exceptions and residual risk summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Reporting exceptions and residual risk when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Reporting exceptions and residual risk escalation until the next scheduled dashboard publication.

Confidentiality of security reports

Reports may expose vulnerabilities, architecture, supplier weaknesses, or incident information and therefore require access control, retention, and distribution rules.

Example: Define audience, source data, thresholds, uncertainty, traceability, escalation, ownership, and required action for Confidentiality of security reports.

Counterexample: Publish one Confidentiality of security reports summary for every audience without preserving drill-down evidence or decision context. | Close a reported issue related to Confidentiality of security reports when a ticket is created rather than when remediation is verified or risk is accepted. | Delay a critical Confidentiality of security reports escalation until the next scheduled dashboard publication.

Integrated risk management

Integrated risk management connects software security risk with enterprise objectives, legal obligations, operational risk, third-party risk, privacy, resilience, and decision governance.

Example: Use Integrated risk management in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Integrated risk management. | Treat compliance or control evidence for Integrated risk management as proof that all material risk is controlled. | Keep the prior Integrated risk management decision after a material change without reassessing assumptions, treatment, or residual exposure.

Regulations, standards, and guidelines as risk inputs

Applicable regulations, standards, and guidelines provide obligations, expected practices, control objectives, and evidence requirements that inform risk decisions.

Example: Use Regulations, standards, and guidelines as risk inputs in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Regulations, standards, and guidelines as risk inputs. | Treat compliance or control evidence for Regulations, standards, and guidelines as risk inputs as proof that all material risk is controlled. | Keep the prior Regulations, standards, and guidelines as risk inputs decision after a material change without reassessing assumptions, treatment, or residual exposure.

ISO sources

ISO standards can inform information-security management, software lifecycle processes, risk management, quality, privacy, and assurance.

Example: Use ISO sources in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with ISO sources. | Treat compliance or control evidence for ISO sources as proof that all material risk is controlled. | Keep the prior ISO sources decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: “ISO compliant” is incomplete without naming the standard, scope, version, and basis of conformity.

PCI sources

PCI requirements apply to defined payment-card environments and relationships.

Example: Continue risk-based reviews for systems and threats outside PCI scope and for risks not fully covered by applicable controls.

Counterexample: Use the successful PCI assessment as evidence that systems outside the cardholder-data environment need no further review. | Repeat PCI testing more often instead of assessing software risks that the standard does not fully address. | Assign all remaining security risk to the payment service provider because processing is outsourced.

Limitations: PCI compliance does not prove that all software security risks are controlled.

NIST sources

NIST publications provide frameworks, risk-management processes, controls, secure-development practices, and technical guidance.

Example: Use NIST sources in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with NIST sources. | Treat compliance or control evidence for NIST sources as proof that all material risk is controlled. | Keep the prior NIST sources decision after a material change without reassessing assumptions, treatment, or residual exposure.

OWASP sources

OWASP resources provide application-security risks, verification guidance, testing guidance, maturity practices, and defensive techniques.

Example: Use OWASP sources in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with OWASP sources. | Treat compliance or control evidence for OWASP sources as proof that all material risk is controlled. | Keep the prior OWASP sources decision after a material change without reassessing assumptions, treatment, or residual exposure.

SAFECode sources

SAFECode practices can inform secure development governance and lifecycle activities.

Example: Use SAFECode sources in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with SAFECode sources. | Treat compliance or control evidence for SAFECode sources as proof that all material risk is controlled. | Keep the prior SAFECode sources decision after a material change without reassessing assumptions, treatment, or residual exposure.

SAMM sources

OWASP SAMM supports current-state assessment and maturity improvement planning.

Example: Use SAMM sources in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with SAMM sources. | Treat compliance or control evidence for SAMM sources as proof that all material risk is controlled. | Keep the prior SAMM sources decision after a material change without reassessing assumptions, treatment, or residual exposure.

BSIMM sources

BSIMM supports observational benchmarking of software security initiatives.

Example: Use BSIMM sources in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with BSIMM sources. | Treat compliance or control evidence for BSIMM sources as proof that all material risk is controlled. | Keep the prior BSIMM sources decision after a material change without reassessing assumptions, treatment, or residual exposure.

Legal risk category

The outline names Legal as one of the integrated-risk-management categories under 2.8.

Example: Use Legal risk category in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Legal risk category. | Treat compliance or control evidence for Legal risk category as proof that all material risk is controlled. | Keep the prior Legal risk category decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: Do not reduce legal risk to compliance checklists; legal obligations may create design, operational, reporting, retention, licensing, and notification consequences.

Legal risk: intellectual property

Intellectual-property risk includes ownership, licensing, patent, copyright, trade-secret, source-code, training-data, and third-party component obligations.

Example: Use Legal risk: intellectual property in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Legal risk: intellectual property. | Treat compliance or control evidence for Legal risk: intellectual property as proof that all material risk is controlled. | Keep the prior Legal risk: intellectual property decision after a material change without reassessing assumptions, treatment, or residual exposure.

Tradeoffs: Domain 8 focuses on acquisition and supply-chain contractual controls; Domain 2 incorporates legal risk into lifecycle governance.

Legal risk: breach notification

Breach-notification obligations may define triggers, affected parties, authorities, content, timing, evidence, and jurisdictional differences.

Example: Use Legal risk: breach notification in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Legal risk: breach notification. | Treat compliance or control evidence for Legal risk: breach notification as proof that all material risk is controlled. | Keep the prior Legal risk: breach notification decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: Notification clocks and definitions vary by law and contract; avoid inventing one universal deadline.

Privacy Impact Assessment and Data Protection Impact Assessment

A Privacy Impact Assessment (PIA) evaluates how a project, system, or processing activity affects privacy and identifies mitigation and governance actions.

Example: Use Privacy Impact Assessment and Data Protection Impact Assessment in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Privacy Impact Assessment and Data Protection Impact Assessment. | Treat compliance or control evidence for Privacy Impact Assessment and Data Protection Impact Assessment as proof that all material risk is controlled. | Keep the prior Privacy Impact Assessment and Data Protection Impact Assessment decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: A PIA or DPIA is not a vulnerability scan, is not required for every processing activity, and does not by itself authorize processing that retains unacceptable or legally prohibited risk.

Tradeoffs: Domain 2 governs when and how the assessment process occurs.

Risk management as an integrated-risk-management category

The outline names Risk management as a separate 2.8 category, illustrated by risk assessment and risk analysis.

Example: Use Risk management as an integrated-risk-management category in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk management as an integrated-risk-management category. | Treat compliance or control evidence for Risk management as an integrated-risk-management category as proof that all material risk is controlled. | Keep the prior Risk management as an integrated-risk-management category decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: Risk assessment and risk analysis are related but not interchangeable; assessment is the broader process, while analysis estimates the nature and level of risk.

Risk assessment

Risk assessment identifies assets, threats, vulnerabilities, existing controls, likelihood, impact, uncertainty, and treatment options.

Example: Use Risk assessment in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk assessment. | Treat compliance or control evidence for Risk assessment as proof that all material risk is controlled. | Keep the prior Risk assessment decision after a material change without reassessing assumptions, treatment, or residual exposure.

Risk analysis

Risk analysis estimates and communicates the nature and level of risk using qualitative, quantitative, or hybrid methods.

Example: Use Risk analysis in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk analysis. | Treat compliance or control evidence for Risk analysis as proof that all material risk is controlled. | Keep the prior Risk analysis decision after a material change without reassessing assumptions, treatment, or residual exposure.

Technical risk versus business risk

Technical risk describes weaknesses and technical consequences.

Example: Use Technical risk versus business risk in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Technical risk versus business risk. | Treat compliance or control evidence for Technical risk versus business risk as proof that all material risk is controlled. | Keep the prior Technical risk versus business risk decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: A technically severe weakness may have low business exposure in one context, while a moderate weakness may be business-critical in another.

Risk appetite and risk tolerance

Risk appetite is the broad amount and type of risk an organization is willing to pursue or retain.

Example: Use Risk appetite and risk tolerance in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk appetite and risk tolerance. | Treat compliance or control evidence for Risk appetite and risk tolerance as proof that all material risk is controlled. | Keep the prior Risk appetite and risk tolerance decision after a material change without reassessing assumptions, treatment, or residual exposure.

Inherent and residual risk

Inherent risk exists before considering controls.

Example: Use Inherent and residual risk in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Inherent and residual risk. | Treat compliance or control evidence for Inherent and residual risk as proof that all material risk is controlled. | Keep the prior Inherent and residual risk decision after a material change without reassessing assumptions, treatment, or residual exposure.

Risk treatment options

Common treatments include avoid, mitigate/reduce, transfer/share, and accept.

Example: Use Risk treatment options in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk treatment options. | Treat compliance or control evidence for Risk treatment options as proof that all material risk is controlled. | Keep the prior Risk treatment options decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: Risk transfer does not eliminate all accountability or operational consequences.

Risk ownership

A risk owner has authority and accountability to make or sponsor treatment and acceptance decisions.

Example: An accountable business risk owner should accept, treat, transfer, or avoid the risk using documented evidence.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk ownership. | Treat compliance or control evidence for Risk ownership as proof that all material risk is controlled. | Keep the prior Risk ownership decision after a material change without reassessing assumptions, treatment, or residual exposure.

Risk register

A risk register records risk statements, causes, consequences, likelihood, impact, controls, treatment, owners, status, review dates, and links to evidence.

Example: Use Risk register in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk register. | Treat compliance or control evidence for Risk register as proof that all material risk is controlled. | Keep the prior Risk register decision after a material change without reassessing assumptions, treatment, or residual exposure.

Qualitative and quantitative analysis

Qualitative analysis uses ordered categories; quantitative analysis estimates numeric frequency and loss.

Example: Use Qualitative and quantitative analysis in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Qualitative and quantitative analysis. | Treat compliance or control evidence for Qualitative and quantitative analysis as proof that all material risk is controlled. | Keep the prior Qualitative and quantitative analysis decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: Numeric output is not automatically more accurate when assumptions and data are weak.

Risk aggregation and concentration

Individually acceptable risks can combine into material exposure through shared dependencies, common controls, suppliers, platforms, identities, or data stores.

Example: Use Risk aggregation and concentration in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk aggregation and concentration. | Treat compliance or control evidence for Risk aggregation and concentration as proof that all material risk is controlled. | Keep the prior Risk aggregation and concentration decision after a material change without reassessing assumptions, treatment, or residual exposure.

Risk review triggers

Reassess risk after material changes, new threats, incidents, significant findings, supplier changes, regulatory changes, model retraining, or control failures.

Example: Use Risk review triggers in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Risk review triggers. | Treat compliance or control evidence for Risk review triggers as proof that all material risk is controlled. | Keep the prior Risk review triggers decision after a material change without reassessing assumptions, treatment, or residual exposure.

Compliance-driven and risk-driven security

Compliance-driven security satisfies applicable legal, regulatory, contractual, and policy obligations.

Example: Use Compliance-driven and risk-driven security in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with Compliance-driven and risk-driven security. | Treat compliance or control evidence for Compliance-driven and risk-driven security as proof that all material risk is controlled. | Keep the prior Compliance-driven and risk-driven security decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: Do not treat compliance and security as mutually exclusive, and do not use risk analysis to disregard mandatory requirements.

SBOM as a lifecycle risk-governance input

A Software Bill of Materials (SBOM) provides structured visibility into software components and dependency relationships.

Example: Use SBOM as a lifecycle risk-governance input in a documented business decision with scope, assumptions, owner, treatment, residual risk, and review triggers.

Counterexample: Let the technical analyst accept the residual business risk associated with SBOM as a lifecycle risk-governance input. | Treat compliance or control evidence for SBOM as a lifecycle risk-governance input as proof that all material risk is controlled. | Keep the prior SBOM as a lifecycle risk-governance input decision after a material change without reassessing assumptions, treatment, or residual exposure.

Limitations: An SBOM provides visibility; it does not prove that components are secure, vulnerability-free, correctly configured, properly licensed, or trustworthy.

Tradeoffs: Domain 2 governs SBOM ownership, currency, quality, and decision use.

Secure operation practices within lifecycle management

Domain 2 establishes management practices that connect development with controlled operation: change management, incident planning, verification and validation, and assessment and authorization.

Example: Use the approved process for Secure operation practices within lifecycle management, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Secure operation practices within lifecycle management. | Allow the implementation team to approve its own exception for Secure operation practices within lifecycle management. | Reuse the previous authorization for Secure operation practices within lifecycle management after material changes or control failures.

Tradeoffs: Domain 7 performs detailed deployment, monitoring, incident response, patching, and operational maintenance.

Change management process

Change management ensures proposed changes are requested, assessed, approved, tested, documented, scheduled, implemented, verified, and reversible according to risk.

Example: Use the approved process for Change management process, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Change management process. | Allow the implementation team to approve its own exception for Change management process. | Reuse the previous authorization for Change management process after material changes or control failures.

Security impact analysis for changes

Assess changes for effects on requirements, architecture, data, privileges, interfaces, dependencies, controls, tests, documentation, compliance, and residual risk.

Example: Use the approved process for Security impact analysis for changes, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Security impact analysis for changes. | Allow the implementation team to approve its own exception for Security impact analysis for changes. | Reuse the previous authorization for Security impact analysis for changes after material changes or control failures.

Standard, normal, and emergency changes

Standard changes are pre-authorized and repeatable; normal changes receive case-specific review; emergency changes use expedited procedures with compensating oversight and retrospective review.

Example: Use the approved process for Standard, normal, and emergency changes, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Standard, normal, and emergency changes. | Allow the implementation team to approve its own exception for Standard, normal, and emergency changes. | Reuse the previous authorization for Standard, normal, and emergency changes after material changes or control failures.

Limitations: Emergency does not mean unrecorded or exempt from later validation.

Change approval authority

Approval should be proportional to impact and may involve product, security, operations, privacy, legal, architecture, or risk owners.

Example: Use the approved process for Change approval authority, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Change approval authority. | Allow the implementation team to approve its own exception for Change approval authority. | Reuse the previous authorization for Change approval authority after material changes or control failures.

Rollback and contingency planning

Changes should define rollback, recovery, communication, and escalation when failure could materially affect security or availability.

Example: Prepare and test rollback or recovery steps, decision thresholds, responsible roles, communications, and escalation.

Counterexample: Use a meeting note as sufficient evidence that recovery planning occurred. | Proceed despite the absence of a technically viable rollback or recovery path. | Plan to investigate only after the maintenance window closes.

Incident response plan

The incident response plan defines governance, roles, communication, escalation, evidence handling, decision authority, external coordination, and integration with continuity and legal obligations.

Example: Use the approved process for Incident response plan, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Incident response plan. | Allow the implementation team to approve its own exception for Incident response plan. | Reuse the previous authorization for Incident response plan after material changes or control failures.

Tradeoffs: Domain 7 executes triage, forensics, remediation, and root-cause analysis.

Incident preparation across the SDLC

Software should be designed and documented to support detection, investigation, containment, evidence, recovery, and secure correction.

Example: Use the approved process for Incident preparation across the SDLC, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Incident preparation across the SDLC. | Allow the implementation team to approve its own exception for Incident preparation across the SDLC. | Reuse the previous authorization for Incident preparation across the SDLC after material changes or control failures.

Verification and validation

Verification asks whether work products meet specified requirements and were built correctly.

Example: Use the approved process for Verification and validation, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Verification and validation. | Allow the implementation team to approve its own exception for Verification and validation. | Reuse the previous authorization for Verification and validation after material changes or control failures.

Limitations: The terms are related but not interchangeable.

Independence in verification and validation

Independence can improve objectivity and may be required by risk, regulation, contract, or assurance level.

Example: Use the approved process for Independence in verification and validation, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Independence in verification and validation. | Allow the implementation team to approve its own exception for Independence in verification and validation. | Reuse the previous authorization for Independence in verification and validation after material changes or control failures.

Tradeoffs: Domain 6 performs detailed security verification and validation testing.

Assessment and Authorization process

Assessment evaluates whether controls are implemented and effective.

Example: The assessor evaluates evidence; the accountable authorizing official decides whether residual risk is acceptable.

Counterexample: Let the assessor approve continued operation because the assessor understands the findings. | Require the authorizing official to repeat every technical test personally. | Allow the product team to authorize itself after creating remediation tickets.

Limitations: An assessor evaluates; an authorizing official accepts or rejects residual risk.

Authorization package

An authorization package may include the system plan, risk assessment, control assessment results, remediation plan, operating conditions, dependencies, and residual-risk statement.

Example: Use the approved process for Authorization package, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review. | Allow the implementation team to approve its own exception. | Reuse the previous authorization for Authorization package after material changes or control failures.

Authorization decisions

Possible outcomes include authorization, conditional authorization, denial, or requirement for remediation and reassessment.

Example: Use the approved process for Authorization decisions, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review. | Allow the implementation team to approve its own exception. | Reuse the previous authorization for Authorization decisions after material changes or control failures.

Continuous authorization concepts

Where governance permits, current automated evidence and continuous monitoring can support more frequent risk decisions.

Example: Use the approved process for Continuous authorization concepts, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Use urgency to bypass impact analysis, documentation, validation, or retrospective review for Continuous authorization concepts. | Allow the implementation team to approve its own exception for Continuous authorization concepts. | Reuse the previous authorization for Continuous authorization concepts after material changes or control failures.

Separation of assessment and authorization

Separating evidence evaluation from risk acceptance reduces conflict of interest and preserves decision accountability.

Example: Use the approved process for Separation of assessment and authorization, including impact analysis, authority, evidence, recovery or response planning, and retrospective review where required.

Counterexample: Let the assessor approve continued operation because the assessor understands the findings. | Require the authorizing official to repeat every technical test personally. | Allow the product team to authorize itself after creating remediation tickets.

Transition from DevSecOps to MLSecOps

MLSecOps extends lifecycle governance to models, training and evaluation data, feature pipelines, experiments, model registries, retraining, deployment, monitoring, and rollback.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Transition from DevSecOps to MLSecOps.

Counterexample: Approve the AI change for Transition from DevSecOps to MLSecOps based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Transition from DevSecOps to MLSecOps. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Transition from DevSecOps to MLSecOps.

Limitations: MLSecOps supplements rather than eliminates secure software lifecycle controls.

Non-linear continuous retraining loops

AI systems may change through data updates, retraining, fine-tuning, prompt/configuration changes, and model replacement.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Non-linear continuous retraining loops.

Counterexample: Approve the AI change for Non-linear continuous retraining loops based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Non-linear continuous retraining loops. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Non-linear continuous retraining loops.

AI work integrated into Agile sprints

Model-risk work, evaluation, data governance, abuse testing, and monitoring requirements should be planned in backlog and sprint practices rather than handled outside the delivery process.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for AI work integrated into Agile sprints.

Counterexample: Approve the AI change for AI work integrated into Agile sprints based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for AI work integrated into Agile sprints. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for AI work integrated into Agile sprints.

Governance of generative-AI coding assistants

Organizations should define approved tools, permitted data, code ownership, human review, provenance, logging, secret handling, and validation requirements for AI-assisted coding.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Governance of generative-AI coding assistants.

Counterexample: Approve the AI change for Governance of generative-AI coding assistants based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Governance of generative-AI coding assistants. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Governance of generative-AI coding assistants.

Limitations: AI-generated code is not trusted merely because the assistant is enterprise-approved.

Hallucinated vulnerabilities and insecure code

Generative tools can produce plausible but incorrect APIs, controls, dependencies, or code.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Hallucinated vulnerabilities and insecure code.

Counterexample: Approve the AI change for Hallucinated vulnerabilities and insecure code based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Hallucinated vulnerabilities and insecure code. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Hallucinated vulnerabilities and insecure code.

Preventing AI tools from bypassing security gates

Automation and coding assistants must not be allowed to suppress findings, alter approval evidence, or promote artifacts without required policy evaluation and authorization.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Preventing AI tools from bypassing security gates.

Counterexample: Approve the AI change for Preventing AI tools from bypassing security gates based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Preventing AI tools from bypassing security gates. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Preventing AI tools from bypassing security gates.

OWASP Top 10 for LLM Applications

The narrative identifies emerging frameworks such as the OWASP Top 10 for LLM Applications as lifecycle inputs alongside traditional application-security standards.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for OWASP Top 10 for LLM Applications.

Counterexample: Approve the AI change for OWASP Top 10 for LLM Applications based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for OWASP Top 10 for LLM Applications. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for OWASP Top 10 for LLM Applications.

Limitations: A Top 10 list is an awareness and prioritization resource, not a complete assurance standard.

AI-model build-break criteria

Lifecycle gates can block build or release when approved safety, bias, hallucination, robustness, security, or compliance thresholds are exceeded.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for AI-model build-break criteria.

Counterexample: Approve the AI change for AI-model build-break criteria based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for AI-model build-break criteria. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for AI-model build-break criteria.

Limitations: Do not use an undefined “acceptable bias” or “hallucination rate” as a testable gate.

Model and data versioning

Reproducible AI lifecycle management requires versioning of model artifacts, datasets, features, prompts, configurations, evaluation suites, code, and dependencies.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Model and data versioning.

Counterexample: Approve the AI change for Model and data versioning based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Model and data versioning. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Model and data versioning.

Model registry and promotion governance

A model registry can manage lineage, status, approvals, metadata, evaluation evidence, and promotion.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Model registry and promotion governance.

Counterexample: Approve the AI change for Model registry and promotion governance based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Model registry and promotion governance. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Model registry and promotion governance.

Drift as a lifecycle trigger

Data drift, concept drift, performance drift, and safety drift may trigger investigation, retraining, rollback, or reauthorization according to defined thresholds.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Drift as a lifecycle trigger.

Counterexample: Approve the AI change for Drift as a lifecycle trigger based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Drift as a lifecycle trigger. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Drift as a lifecycle trigger.

Tradeoffs: Domain 7 performs operational monitoring; Domain 2 defines the governance loop and decision process.

Human oversight and accountable decisions

AI can assist triage, reporting, and workflow, but material risk acceptance, authorization, and exceptions require accountable human authority unless law and policy explicitly define otherwise.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for Human oversight and accountable decisions.

Counterexample: Approve the AI change for Human oversight and accountable decisions based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for Human oversight and accountable decisions. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for Human oversight and accountable decisions.

AI lifecycle evidence

Evidence may include data lineage, evaluation results, red-team findings, model cards, risk assessments, approvals, change records, monitoring thresholds, and rollback readiness.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for AI lifecycle evidence.

Counterexample: Approve the AI change for AI lifecycle evidence based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for AI lifecycle evidence. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for AI lifecycle evidence.

AI-specific incident preparation

Plans should address model theft, data poisoning, prompt injection, unsafe autonomous action, training-data leakage, drift, provider failure, and model rollback.

Example: Require versioned evidence, defined evaluation criteria, accountable approval, monitoring thresholds, and rollback or response planning for AI-specific incident preparation.

Counterexample: Approve the AI change for AI-specific incident preparation based only on model-registry presence. | Allow the AI workflow to bypass existing release and security gates for AI-specific incident preparation. | Use an undefined quality, hallucination, robustness, bias, or drift threshold as the release criterion for AI-specific incident preparation.