Lesson A15.5
Frameworks and control catalogs help organizations organize security work, but a checklist is not the same as a risk program. This lesson teaches how requirements, controls, evidence, applicability, and exceptions fit together without confusing compliance with security.
All examples use fictional requirements, mappings, control IDs, policies, and evidence. No real confidential audit or compliance data is required.
Lesson Progress
High School Advanced • A15: Risk Management and Compliance • Lesson 5 of 10
Readiness Check
0/4 ready
Professional Hook
Compliance answers an important question: are applicable requirements being met with enough evidence to support the conclusion? Security asks a broader question: is the organization managing actual risk well? Strong programs need both.
Frameworks organize the work; risk tells you what matters most.
Learning Objectives
Explain the purpose of cybersecurity frameworks, standards, control catalogs, policies, procedures, and evidence mappings.
Distinguish security effectiveness from compliance status so that a passed control requirement is not treated as proof that all relevant risk is solved.
Evaluate applicability, control ownership, evidence, exceptions, compensating controls, and review cadence in a compliance mapping.
Connect risk records and control-effectiveness results to broader governance requirements without forcing one framework to become the entire security program.
Build a Framework and Control Mapping Register that becomes the fifth artifact in the A15 Risk Register and Leadership Recommendation.
Governance Layers
Creates external obligations that may apply because of geography, sector, data type, contract, or business relationship.
Example: A contract requires specific security evidence or incident-notification expectations.
Review: Why is this obligation applicable to the organization or service?
Provides a structured way to organize cybersecurity activities, outcomes, or control domains.
Example: A framework may group work into governance, protection, detection, response, recovery, and supplier-risk themes.
Review: How does the framework help organize the security program?
Defines more specific security requirements or controls that can be assessed.
Example: A control catalog may define access review, logging, backup, supplier review, or configuration-management expectations.
Review: What measurable requirement must the organization satisfy?
States the organization's mandatory security expectations.
Example: Sensitive data must be protected and access reviewed according to approved standards.
Review: What organizational rule or outcome is mandatory?
Describes how an approved process is carried out.
Example: Quarterly access review, risk exception approval, or backup validation procedure.
Review: Can teams follow the process consistently and produce evidence?
Shows whether the requirement or control is designed and operating as intended.
Example: Current access review, recovery test, supplier assessment, policy approval, or control-test result.
Review: What current evidence supports the compliance conclusion?
Compliance and Security
Meeting an applicable requirement and producing enough evidence to demonstrate that status.
Useful for: Consistency, accountability, audits, contractual obligations, governance, baseline expectations.
Limitation: A requirement may be narrow, outdated, or insufficient for a new threat or business context.
Managing risk so that systems, data, identities, services, and business objectives are reasonably protected.
Useful for: Risk reduction, architecture, resilience, prevention, detection, response, recovery, and adaptive decision making.
Limitation: Security can be difficult to measure perfectly and requires judgment beyond checklists.
Uses compliance requirements as one input while continuing to evaluate actual risk and control effectiveness.
Useful for: Keeping required controls aligned with business risk.
Limitation: Still requires current evidence, ownership, exceptions, and leadership decisions.
Applicability
Why: A requirement should not be applied or excluded without understanding the actual system and data boundary.
Evidence: Service inventory, data classification, architecture scope, contract scope.
Why: Compliance conclusions need a clear applicability basis.
Evidence: Policy, contract, standard, framework mapping, legal interpretation where authorized.
Why: A requirement should map to a real security control or governance process.
Evidence: Control ID, control owner, objective, design review, operating evidence.
Why: Organizations often reuse the same control across several frameworks or policies.
Evidence: Crosswalk, mapping register, evidence reuse, control objective.
Why: Coverage may be incomplete across systems, identities, regions, or workflows.
Evidence: Population inventory, exception list, control coverage, test results.
Why: A mapping without evidence is only an assertion.
Evidence: Current logs, reviews, approvals, assessments, test results, owner attestations.
Mapping Anatomy
Makes the requirement traceable across reviews and evidence.
Strong: Stable identifier such as GOV-AC-01 or FRAME-PR-07.
Weak: “Access requirement.”
Explains the actual expected security or governance outcome.
Strong: Privileged access must be reviewed at an approved cadence and after material role change.
Weak: “Check admins.”
Explains why the requirement is in scope.
Strong: Applies to production workforce privileged access because the service processes sensitive data.
Weak: “Probably applies.”
Connects the requirement to a specific safeguard.
Strong: CTL-201 Quarterly Workforce Access Review.
Weak: “IAM controls.”
Creates accountability for operation and evidence.
Strong: Identity Governance.
Weak: “IT.”
Supports the conclusion with current proof.
Strong: Current quarterly review record, exception list, and remediation closure.
Weak: “Screenshot available.”
Communicates the current compliance decision clearly.
Strong: Met, Partially Met, Not Met, Not Applicable, Compensating, Unknown.
Weak: “Fine.”
Keeps incomplete coverage visible.
Strong: Two legacy admin accounts remain under approved exception until migration.
Weak: “Some exceptions.”
Prevents mappings from becoming stale.
Strong: Quarterly plus event-driven review after architecture or ownership change.
Weak: “Review sometimes.”
Compliance Status
Current evidence supports the requirement across the intended scope.
The requirement is satisfied for some but not all intended scope or control conditions.
Current evidence shows a material requirement is not satisfied.
Evidence is insufficient, stale, missing, or contradictory.
An approved alternate control temporarily supports the requirement while the preferred control is unavailable.
The requirement does not apply to the reviewed scope, with documented rationale.
Crosswalks
Example: A strong access review can support internal policy, audit, supplier, and framework requirements.
Benefit: Reduces duplicate work when control objectives are genuinely equivalent.
Caution: Do not assume every similarly worded requirement has identical scope or evidence needs.
Example: A sensitive-data protection requirement may rely on access control, encryption, monitoring, and recovery.
Benefit: Shows that complex outcomes often depend on several safeguards.
Caution: Do not reduce a broad requirement to one convenient control.
Example: One current control test may support several mappings if the tested scope matches each requirement.
Benefit: Improves efficiency and consistency.
Caution: Check date, scope, owner, population, and objective before reusing evidence.
Example: If a shared access-review control fails, several mapped requirements may become Partially Met or Not Met.
Benefit: Shows why control quality matters across the governance program.
Caution: Update every affected mapping rather than only the original risk record.
Design Principles
A framework helps structure the program, but actual business risk still drives priority.
Review: Which high-risk issue deserves action even if no audit deadline is near?
A requirement should not be included or excluded without rationale.
Review: What business, data, contract, or policy basis makes this applicable?
A requirement should connect to one or more specific safeguards.
Review: Can the reviewer identify the actual control owner and expected outcome?
Convenient evidence is not always relevant evidence.
Review: Does the evidence prove the exact requirement across the correct scope?
A control that works for most systems can still leave the requirement Partially Met.
Review: Which systems, users, suppliers, or environments remain outside coverage?
An approved exception may govern the gap, but the underlying requirement is still not fully satisfied.
Review: Is the status Met, Partially Met, or Compensating rather than falsely complete?
Architecture and control changes can invalidate previous evidence.
Review: What evidence must be refreshed after change?
A mature organization may implement stronger controls than the minimum requirement.
Review: Which business risks justify stronger protection than the baseline?
Vocabulary
A structured model for organizing cybersecurity outcomes, activities, or control domains.
A collection of specific security or governance controls that can be implemented and assessed.
An expected security, governance, contractual, policy, or regulatory outcome.
The reason a requirement does or does not apply to a defined business or technical scope.
The relationship between a requirement and the control or controls used to satisfy it.
A comparison that shows relationships between requirements across frameworks, standards, or policies.
The connection between a requirement or control and the evidence used to support its status.
An approved alternate safeguard used when the preferred requirement cannot currently be met.
A documented conclusion that a requirement does not apply to the reviewed scope.
A formally approved, bounded deviation from a required policy or standard.
The current conclusion about whether an applicable requirement is met, partially met, not met, unknown, or otherwise governed.
Using one evidence source to support multiple requirements when the scope and objective genuinely align.
Fictional Mapping Register
Applicability
Applies to production privileged identities supporting Student Services.
Mapped control(s)
CTL-201 Quarterly Workforce Access Review
Control owner
Identity Governance
Evidence
Current quarterly review + exception list + completed remediation
Gap / exception
No material gap
Related risk(s)
RSK-101
Review cadence
Quarterly + role-change trigger
Next action
Maintain evidence freshness and update after identity-model changes
Applicability
Applies to Legacy Reporting Service because preferred controls cannot yet be fully implemented.
Mapped control(s)
CTL-202 Legacy Reporting Network Restriction + modernization exception
Control owner
Infrastructure Security + Reporting Product Owner
Evidence
Current network review + current exception + partial modernization evidence
Gap / exception
Obsolete trust, unowned key relationship, and transport gaps remain
Related risk(s)
RSK-102
Review cadence
Monthly + exception expiry
Next action
Complete modernization and retire compensating status when closure evidence exists
Applicability
Applies to partner scheduling certificate and relying-service relationship.
Mapped control(s)
CTL-203 Partner Certificate Renewal Monitoring
Control owner
Integration Platform
Evidence
Current certificate + alert + renewal ticket + sponsor confirmation
Gap / exception
Replacement certificate validation not yet complete
Related risk(s)
RSK-103
Review cadence
Monthly until renewal closes
Next action
Validate replacement and retire old trust before expiry
Applicability
Applies to backup repository and dependent critical services.
Mapped control(s)
CTL-204 Backup Restore Validation
Control owner
Resilience Team
Evidence
Current restore test + key-version mapping + issue closure
Gap / exception
No material gap under current evidence
Related risk(s)
RSK-104
Review cadence
Annual + major platform change
Next action
Repeat validation on schedule and after major architecture changes
Applicability
Applies to critical SaaS provider because the organization depends heavily on the service.
Mapped control(s)
CTL-205 Supplier Continuity Review
Control owner
Vendor Management + Business Service Owner
Evidence
Current supplier assessment + contract + continuity plan
Gap / exception
No practical alternate provider exists
Related risk(s)
RSK-105
Review cadence
Annual + contract renewal + material supplier change
Next action
Improve alternate operating procedures and exit planning
Applicability
Applies to analytics export staging and temporary data-science workspaces.
Mapped control(s)
CTL-206 Analytics Export Cleanup + CTL-207 Temporary Workspace Destruction
Control owner
Analytics Platform + Data Science Platform
Evidence
Current export cleanup evidence + partial workspace cleanup evidence
Gap / exception
Workspace destruction evidence incomplete
Related risk(s)
RSK-106, RSK-107
Review cadence
Monthly + project-close trigger
Next action
Refresh full-population workspace cleanup evidence
Applicability
Applies across all in-scope production security controls.
Mapped control(s)
CTL-201 through CTL-207 control-governance records
Control owner
Security Governance
Evidence
Control register + owner attestations + current control-test results
Gap / exception
CTL-207 evidence remains incomplete
Related risk(s)
Multiple A15 risks
Review cadence
Quarterly
Next action
Refresh CTL-207 evidence and keep control ownership current
Fake Dashboard
Fictional compliance status, control mapping, evidence, and exception summary
Requirements mapped
7
Access, legacy, PKI, recovery, supplier, retention, and control-governance requirements
Met
2
Privileged access review and recovery validation currently satisfy requirements
Partial / Compensating
5
Lifecycle, supplier, retention, legacy, and governance mappings have bounded gaps
Unknown
0
Current mappings have enough evidence for a stated decision
Fake SOC Alert
Source: Fictional Compliance Mapping Review • Time: 10:20
Minimum Requirement vs. Business Risk
A requirement may define a minimum acceptable control. A business service can still justify stronger protection because of criticality, data sensitivity, supplier concentration, or new threat conditions. Mature programs do not stop thinking when the checkbox turns green.
“Does the applicable requirement have enough current evidence to support the stated status?”
“Given our business context, controls, dependencies, and uncertainty, is the remaining risk acceptable?”
Fake Log Panel
[08:20] MAP-301 requirement=PRIVILEGED_ACCESS status=MET evidence=CURRENT [08:44] MAP-302 requirement=LEGACY_CONTROL status=COMPENSATING exception=CURRENT [09:08] MAP-303 requirement=CERT_LIFECYCLE status=PARTIAL replacement=OPEN [09:32] MAP-304 requirement=RECOVERY_TEST status=MET evidence=CURRENT [09:56] MAP-305 requirement=SUPPLIER_CONTINUITY status=PARTIAL concentration=OPEN [10:20] MAP-306 requirement=TEMP_DATA_RETENTION status=PARTIAL workspace_evidence=INCOMPLETE [10:44] MAP-307 requirement=CONTROL_GOVERNANCE status=PARTIAL CTL207=UNKNOWN
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Common Compliance Mistakes
Why it fails: The organization treats a passed audit as proof that all major security risk is solved.
Better approach: Use compliance as one input and continue evaluating actual business risk.
Why it fails: A requirement says 'use IAM' without a specific control owner, scope, or objective.
Better approach: Map to a concrete control with a clear expected outcome.
Why it fails: One test is copied across many requirements even though the tested population differs.
Better approach: Verify objective, population, date, owner, and scope before reuse.
Why it fails: An approved exception is treated as if the preferred requirement is fully satisfied.
Better approach: Use Compensating or Partially Met while keeping the underlying gap visible.
Why it fails: A team excludes a difficult requirement with no documented basis.
Better approach: Record scope, reason, owner, and supporting evidence for Not Applicable decisions.
Why it fails: Teams work only on listed requirements and ignore new risks or business changes.
Better approach: Use frameworks to organize work while risk analysis drives priority.
Why it fails: Architecture, data, supplier, or control changes occur but old mappings remain untouched.
Better approach: Add scheduled and event-driven review triggers.
Why it fails: The organization refuses stronger controls because the baseline requirement is already satisfied.
Better approach: Exceed minimum requirements when business risk justifies stronger protection.
Scenario Decision Lab
A legacy service cannot yet meet the preferred control standard, but a current exception and alternate safeguards are reducing risk during modernization.
Scenario Decision Lab
A temporary-data retention requirement is satisfied for analytics export staging, but evidence is incomplete for temporary data-science workspaces.
Safe Fictional Lab
Use fictional requirements, policies, controls, evidence, owners, mappings, and exceptions only. Focus on traceability and governance, not real regulatory interpretation.
Create at least twenty-five fictional mapping records.
Give every record a stable MAP ID.
Record the requirement ID.
Write the requirement statement.
Record the source category: policy, standard, contract, framework, or internal control catalog.
Record applicability rationale.
Record business/service scope.
Map one or more CTL IDs.
Map related RSK IDs.
Record the control owner.
Record the evidence source.
Record evidence freshness.
Record status as Met, Partially Met, Not Met, Unknown, Compensating, or Not Applicable.
Record gap or exception details.
Record compensating controls where applicable.
Record review cadence.
Record change triggers.
Record next action.
Include at least five one-control-to-many-requirement mappings.
Include at least five many-controls-to-one-requirement mappings.
Include at least three Partially Met requirements.
Include at least two Compensating requirements.
Include at least two Not Applicable examples with rationale.
Include at least two Unknown examples with missing or stale evidence.
Include at least two Not Met examples with explicit remediation.
Create a small crosswalk showing how three different requirement sets overlap.
Identify where one control failure would affect multiple mappings.
Identify where a requirement is technically Met but business risk still justifies stronger protection.
Lab boundary
Do not collect confidential audit reports, private contracts, legal advice, or restricted compliance evidence. Do not treat this fictional lab as legal or regulatory guidance. Use synthetic requirements and provider-neutral examples only.
Analyze the Evidence
Advanced Challenge
Create a fictional organization-wide standard that explains how requirements are mapped to controls, how evidence is reused, how exceptions are represented, and when a mapping must be refreshed.
Requirement ID format
Applicability criteria
Control mapping rules
Risk mapping rules
Evidence ownership
Evidence reuse criteria
Crosswalk method
Status definitions
Partially Met rules
Not Applicable rationale
Compensating control rules
Exception references
Review cadence
Change triggers
Audit traceability
Leadership reporting
The strongest standard should reduce duplicate work without hiding scope differences, exceptions, or actual security risk.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the fifth artifact for your A15 Risk Register and Leadership Recommendation: a fictional Framework and Control Mapping Register with at least twenty-five records. Include MAP ID, requirement ID, requirement statement, source category, applicability rationale, business/service scope, mapped CTL IDs, mapped RSK IDs, control owner, evidence, evidence freshness, status, exception or gap, compensating control, review cadence, change trigger, next action, and crosswalk relationships.
Confidence / Readiness Reflection
A15.6 focuses on Audit Evidence and Documentation. Before continuing, make sure every compliance conclusion in your mapping register can point to evidence that is current, relevant, complete, and attributable.
I can distinguish a framework from a control catalog, policy, procedure, and evidence.
I can explain why compliance and security are related but not identical.
I can map a requirement to one or more specific controls.
I can use Partially Met or Compensating when full coverage is not proven.
I can explain when evidence reuse is valid and when it is misleading.
Portfolio Build Guide
A requirement should have a documented reason for being in or out of scope.
Use stable CTL IDs, owners, objectives, and evidence rather than vague technology categories.
Use Met, Partially Met, Not Met, Unknown, Compensating, or Not Applicable consistently.
Do not hide gaps just because they are formally approved.
Check objective, population, date, owner, and scope before one evidence source supports several requirements.
Make overlapping requirements visible so controls can be managed consistently across frameworks.
Compliance status should inform risk decisions, but should not replace them.
A15.6 will evaluate evidence quality, documentation, freshness, traceability, and audit readiness.
Key Takeaways
Lesson Safety Boundary
Do not collect confidential contracts, restricted audit reports, legal advice, or private compliance records. Do not treat this lesson as legal or regulatory guidance. All requirements, mappings, controls, evidence, organizations, and exceptions are fictional.
Lesson Complete
You now have a structured model for frameworks, requirements, applicability, control mappings, crosswalks, evidence reuse, exceptions, and compliance status. Next, A15.6 focuses on Audit Evidence and Documentation.