Security Certification and Authorization Within the SDLC

Defines how Security certification and authorization should evaluate Security claims, controls, evidence, residual Risk, and operating conditions before an authorized decision permits Production use or continued operation.

Best Practice: Define the Purpose and Intended Outcome of Security Certification and Authorization Within the SDLC

Security certification evaluates whether Security requirements and controls have been implemented and evidenced against an approved basis. Security authorization is the accountable decision to permit operation or use under defined conditions and with explicit treatment of residual Security Risk.

Benefits: Separating Security certification — an evidence-based assessment — from Security authorization — the accountable decision to operate — prevents a passed assessment from being mistaken for permission to proceed. The distinction matters because an assessor can find controls implemented correctly while the authorizing authority still has grounds to restrict or deny operation based on residual Risk.

Best Practice: Distinguish Certification From Authorization

Certification produces an evidence-based assessment or attestation. Authorization is a governance decision made by a designated authority. The assessor should not be assumed to own the operating decision or accept residual Risk unless explicitly assigned that authority.

Benefits: Making clear that the assessor doesn’t automatically own the operating decision prevents a common confusion: a Security team that certifies technical controls being assumed, incorrectly, to also have accepted the residual Risk of running the Solution. Those are two different roles that should stay explicitly separate.

Best Practice: Define the Authorization Boundary

The boundary should identify the complete Solution, components, data, interfaces, users, Environments, suppliers, shared Services, trust relationships, and operational dependencies whose Security state affects the authorization decision.

Benefits: Explicitly scoping the authorization boundary to include shared Services and supplier dependencies — not just the Solution’s own components — prevents an authorization from covering less than what the Solution actually depends on. A boundary that quietly excludes a shared platform leaves that platform’s Security posture unaccounted for in the decision.

Best Practice: Define Security Claims and Evidence

Claims should address applicable confidentiality, integrity, availability, identity, access, logging, monitoring, vulnerability, resilience, recovery, supplier, data-protection, and Incident-response requirements. Evidence should be current, attributable, configuration-specific, and proportionate to consequence.

Benefits: Requiring evidence to be current and configuration-specific, rather than a general Security posture statement, means the authorization decision reflects how the Solution is actually configured today, not how a similar system was configured when a template evidence package was first assembled.

Best Practice: Apply Evaluate Residual Risk and Conditions

Open vulnerabilities, control limitations, inherited controls, exceptions, deferred obligations, monitoring gaps, and untested conditions should be visible to the Risk Owner and authorization authority. Authorization may be unconditional, conditional, time-limited, restricted, denied, or revoked.

Benefits: Making open vulnerabilities and control limitations visible to the Risk Owner before authorization — rather than only to the engineering team that found them — is what allows a conditional or time-limited authorization to actually reflect the real residual exposure instead of an unconditional approval that quietly overlooks it.

Best Practice: Maintain Authorization Through Change

Material changes to Architecture, data, exposure, suppliers, identity, configuration, Model behavior, vulnerabilities, or operating context should trigger impact analysis and, where required, reassessment or reauthorization. Authorization should not be treated as permanent.

Benefits: Treating a material Architecture or supplier change as a trigger for reassessment, rather than assuming a prior authorization still holds, closes the gap where a Solution’s Security posture has genuinely shifted but its authorization paperwork has not caught up.

Best Practice: Integrate With Release and Operations

Security authorization evidence should support Readiness Gates and Production decisions while remaining linked to the Release baseline. Operations should monitor authorization conditions, control health, vulnerabilities, Incidents, exceptions, and expiration or reassessment triggers.

Benefits: Linking Security authorization evidence directly to the Release baseline, and having Operations monitor authorization conditions afterward, keeps an authorization decision connected to the exact configuration it covers instead of becoming a static approval that drifts out of sync with what’s actually running.

Best Practice: Apply Security Certification and Authorization Within the SDLC Across Solution Types

Custom-Built Solutions permit direct review of engineering and configuration evidence. Acquired Solutions require supplier evidence plus enterprise configuration, integration, and intended-use assessment. Composite Solutions require end-to-end treatment of shared and divided Security responsibilities.

Benefits: Requiring enterprise-specific configuration and integration evidence for Acquired Solutions, not just supplier-provided evidence, catches the vulnerabilities that only emerge from how the enterprise specifically deployed and connected the Product — exactly the gap a supplier’s own certification cannot cover.

Best Practice: Advance Maturity Deliberately for Security Certification and Authorization Within the SDLC

At Crawl maturity, define the boundary, core Security evidence, Risk Owner, and authorization decision. At Walk maturity, use repeatable control traceability, independent assessment, conditional authorization tracking, and reassessment triggers. At Run maturity, use continuous control evidence, automated baseline correlation, near-real-time Risk signals, and event-driven authorization review.

Benefits: Starting with a clearly defined boundary and a named Risk Owner at Crawl maturity establishes the accountability that repeatable control traceability and conditional-authorization tracking at Walk maturity depend on. Pursuing continuous, automated Risk signals at Run maturity before basic ownership and evidence practices are solid tends to generate alerts no one is positioned to act on.

Best Practice: Avoid Common Antipatterns in Security Certification and Authorization Within the SDLC

Enterprises should avoid treating Security authorization as permanent rather than conditional on change. A material change to Architecture, data, suppliers, or vulnerabilities can invalidate a prior authorization, so treating it as a one-time, permanent approval leaves later changes ungoverned.

Benefits: Avoiding this antipattern keeps authorization decisions synchronized with what is actually running. It closes the gap where a Solution’s Security posture has genuinely shifted but its authorization paperwork has not caught up.

Connections to Related IF4IT Practices and Inventories

Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to connect the decisions and responsibilities addressed in this chapter to governed technology choices, platform lifecycle, and environment controls.

Weave security, privacy, Risk, compliance, audit, and authorization controls through the decisions and responsibilities addressed in this chapter so evidence, exceptions, residual Risk, and accountable approvals stay visible and governed.

Apply the Non-Functional Requirements (NFRs) Framework for Software Systems so quality expectations stay connected to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance.