CAS-005 Governance, risk, and compliance

Governance, risk, and compliance Detailed Explanation

CAS-005 governance questions usually test whether a security decision can be defended with ownership, scope, evidence, and approved risk logic. In this domain, the strongest answer rarely stops at a policy name or a tool purchase; it connects requirements to accountable owners, affected assets, third-party dependencies, compliance timing, and monitoring proof. Read each scenario as an audit trail: what is required, who owns it, what system is in scope, what evidence is current, and what exception or residual-risk decision has been approved.

Governance Components and Security Program Evidence

Exam Radar

Official Objective Mapping: Governance, risk, and compliance; related CAS-005 objective areas: 1.1 organizational security requirements and governance components; 1.4 change/configuration management; GRC tool mapping, automation, reporting, and compliance tracking.

Plain-English Understanding: This topic tests whether you can prove that a governance requirement is actually owned, implemented, monitored, and auditable. Do not choose a tool only because it sounds familiar. First decide whether the issue is policy authority, ownership, asset scope, evidence freshness, or exception handling.

Key Concepts: policy / standard / procedure separation; RACI accountability; CMDB and asset lifecycle; GRC evidence mapping; continuous monitoring evidence.

Exam Focus: audit-style wording where the real missing piece is not the security control itself, but the traceable chain between requirement, accountable owner, affected asset, evidence date, and exception handling.

• Core Priority: Treat governance as a proof chain. The strongest answer connects policy intent to ownership, implementation evidence, asset scope, and review cadence.
• High Frequency: CAS-005 often gives partial governance artifacts and asks which missing link prevents the organization from proving control effectiveness.
• Confusion Alert: A new tool, renamed document, or one-time screenshot is not enough when the scenario says ownership or evidence is inconsistent.
• Scenario Logic: Look for words such as audit gap, unclear owner, stale evidence, undocumented exception, or inconsistent business-unit procedure.
• Version Delta: SecurityX expects governance to be operationalized through GRC workflows, CMDB scope, continuous monitoring, and management commitment.
• Failure Trigger: Controls fail governance review when assets, owners, and evidence are not tied to the same requirement.
• Operational Dependency: The GRC mapping must show who owns the control, which systems are in scope, what evidence is current, and what exception path exists.
• How the Exam Asks It: The question usually asks for the next defensible action after auditors find mismatched procedures or incomplete evidence.
• How Distractors Are Designed: Wrong answers often improve appearance but not auditability, such as renaming procedures or collecting manual screenshots.
• Why the Correct Answer Works: It restores the missing governance linkage instead of treating policy publication as proof of enforcement.

Practice Question: A new encryption standard exists, but auditors find that several production databases have no listed control owner and no current exception record. What is the best next action?

A. Create a traceable GRC mapping from the standard to database assets, accountable owners, evidence dates, and exception workflow B. Ask administrators to rename the database configuration files to match the standard C. Disable database access until every screenshot is manually uploaded D. Replace the CMDB with a vulnerability scan report

Correct Answer: A

Explanation: A is the best answer because the audit problem is the missing governance chain: standard, affected databases, accountable owners, evidence dates, and exception handling. Renaming files does not prove enforcement. Disabling access may be disproportionate before scope is validated. A vulnerability scan can reveal findings, but it cannot replace ownership and compliance evidence.

Practice Question: During a board review, security leadership asks why a privileged-access control is marked effective. Which evidence is most defensible?

A. A slide stating that privileged access is important B. A list of all administrators copied from an old ticket C. A vendor brochure for a PAM product D. A dashboard showing mapped privileged-access requirements, accountable owner approval, covered assets, last test result, and open exceptions

Correct Answer: D

Explanation: D is correct because it shows the control's requirement, owner, asset coverage, test result, and exception state in one evidence path. A slide is an assertion. An old admin list may be stale and does not prove control status. A vendor brochure describes capability, not implementation.

Exam Takeaway: If the stem mentions audit gaps, unclear ownership, stale evidence, or inconsistent procedures, choose the option that reconnects requirement, asset, owner, evidence date, and exception state.

Atomic Deconstruction - Operational Level

What this topic really tests: can you turn a broad governance requirement into an auditable chain of ownership and evidence? Start with the control intent, then attach the requirement to a named owner, scoped assets, implementation evidence, review cadence, and exception path. A policy without RACI ownership is hard to enforce; a CMDB record without control mapping is just inventory; evidence without timestamp and reviewer context does not prove continuous monitoring. The exam often hides the answer in words such as inconsistent evidence, unclear ownership, or audit gap.

Beginner-friendly grounding: Think of governance as the paper trail that proves security is not just promised but actually operated. A control is defensible only when the requirement, owner, affected assets, evidence date, and exception process point to the same story.

Exam transformation: wrong options usually appear as renaming documents instead of proving enforcement; buying a tool before fixing ownership; collecting one-time screenshots instead of continuous evidence; treating a policy as proof that a control works. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Security policy	Control intent and scope	Enterprise-wide or business-unit scoped	Approved baseline	Management commitment and standards	Teams implement inconsistent controls without an auditable requirement source
RACI matrix	Ownership assignment	Responsible, accountable, consulted, informed	Undefined until program design	Security program management	Gaps appear when reporting, exception approval, or incident escalation has no accountable owner
CMDB record	Asset identity and lifecycle state	Owned, deployed, retired, exempt	Unknown or unmanaged	Inventory and change management	Controls cannot be validated because the asset is not tied to owner, criticality, or configuration baseline
GRC platform mapping	Framework-to-control relationship	One-to-many or many-to-one mappings	Manual spreadsheet or no mapping	Compliance tracking and documentation	Audit evidence becomes stale and cannot prove continuous monitoring

Step-by-Step Execution Path

1. Start with the requirement statement and identify whether it is a policy, standard, procedure, or guideline. This prevents treating optional guidance as a mandatory control.
2. Trace each mandatory requirement to a RACI owner and an implementation artifact such as an access policy, baseline, or training record. Ownership unlocks escalation and evidence collection.
3. Verify the affected assets in the CMDB or inventory and confirm lifecycle state, owner, criticality, and exception status. Unowned assets cannot be reliably governed.
4. Inspect GRC mappings for control objective, framework reference, evidence owner, last evidence date, and exception workflow. Version-aware GRC or portal verification should show active mapping, not only a document upload.
5. Review dashboard or report output for control coverage and overdue evidence. The expected state is traceable evidence with accountable owners and no orphaned assets.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain begins with a governance requirement such as privileged access, encryption, or asset ownership. That requirement becomes enforceable only when a policy or standard defines the expectation, a RACI entry assigns accountability, a CMDB or inventory record defines scope, and a GRC workflow tracks evidence. If any link is missing, the organization may have documents but cannot prove control effectiveness. That is why the correct answer usually restores traceability before buying tools or collecting ad hoc artifacts.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate policy-to-control mapping	GRC tool: control library > requirement mapping > evidence tab	Each mandatory requirement has a mapped control, evidence owner, status, and review date
Confirm accountable ownership	Program documentation path: security program > RACI matrix > privileged access standard	One accountable owner and clear responsible teams are assigned for implementation and reporting
Inspect asset coverage	CMDB or inventory query: filter by control scope and privileged-access dependency	Assets in scope have owner, criticality, lifecycle state, and exception flag
Review monitoring status	Compliance dashboard: control status > overdue evidence > exception queue	No critical assets rely on expired evidence or undocumented exception approval

Risk Management, Third-Party Exposure, and Resilience Decisions

Exam Radar

Official Objective Mapping: Governance, risk, and compliance; related CAS-005 objective areas: risk management strategies, third-party risk, compliance obligations, business continuity, disaster recovery, backup, and breach response decision logic.

Plain-English Understanding: This topic tests whether you can prioritize risk treatment when business impact, vendor dependency, legal obligation, and recovery capability collide. The safest exam answer usually validates impact, obligations, restore evidence, and residual risk before choosing a treatment.

Key Concepts: risk appetite; residual risk; third-party due diligence; contractual notification; RPO / RTO; backup isolation and restore testing.

Exam Focus: decide whether the scenario is about business impact, vendor obligation, recovery evidence, or formal risk acceptance before selecting mitigation.

• Core Priority: Risk decisions must be anchored to impact, likelihood, exposure, compensating controls, and an approved risk appetite.
• High Frequency: Questions commonly mix vendor breach, restore failure, regulatory timing, and executive acceptance to test prioritization.
• Confusion Alert: Do not dismiss a risk because it started at a third party; inherited service, data, and notification risk can still belong to the organization.
• Scenario Logic: Separate technical severity from business consequence. A lower CVSS issue may outrank a critical finding if the exploit path and data impact are stronger.
• Version Delta: CAS-005 places more weight on resilience evidence, third-party exposure, AI adoption risk, and operational risk decisions than older purely technical items.
• Failure Trigger: Backups, contracts, or risk registers become weak evidence when they are not tested, current, or approved by the right owner.
• Operational Dependency: A defensible risk decision needs impact analysis, obligation review, treatment choice, residual-risk documentation, and owner approval.
• How the Exam Asks It: The stem may ask what to do first after a vendor incident, failed restore test, or risk-acceptance request.
• How Distractors Are Designed: Wrong answers often patch a visible symptom, wait for the vendor, or accept risk without documented authority.
• Why the Correct Answer Works: It aligns risk treatment with business tolerance and evidence rather than reacting to a single technical clue.

Practice Question: A vendor outage affects a regulated customer portal. The contract has a 24-hour notification clause and the last restore test missed the RTO. What is the first risk-management action?

A. Wait for the vendor to finish its public postmortem before documenting risk B. Delete the vendor from the risk register C. Validate business impact, notification obligations, current recovery capability, and residual risk against approved appetite D. Reclassify the outage as low risk because it is external

Correct Answer: C

Explanation: C is correct because the decision cannot be made from outage status alone. The organization must know customer impact, contractual notification timing, recovery evidence, and whether residual risk exceeds appetite. Waiting or deleting records weakens governance, and calling the issue low risk ignores inherited operational and compliance exposure.

Practice Question: A team proposes accepting a high-impact risk because remediation is expensive. What evidence must exist before acceptance is defensible?

A. A screenshot of the vulnerability scanner home page B. A verbal statement from the application owner C. A list of unrelated patched servers D. Documented residual risk, business impact, compensating controls, owner approval, and alignment with risk appetite

Correct Answer: D

Explanation: D is correct because risk acceptance is a governance decision, not a casual technical preference. The record must show what risk remains, why it is tolerable, which controls reduce exposure, and who is authorized to accept it. The other options are incomplete evidence fragments.

Exam Takeaway: When vendor exposure, restore failure, or legal timing appears in the same scenario, validate impact and obligations before accepting, transferring, or remediating risk.

Atomic Deconstruction - Operational Level

What this topic really tests: can you choose a risk action that matches business consequence rather than technical noise? A third-party event is still your risk when it affects your data, customers, operations, or contracts. A backup is not a resilience control until restore evidence proves RPO and RTO. A risk score is not complete until it includes likelihood, impact, exposure, compensating controls, residual risk, and an accountable decision maker.

Beginner-friendly grounding: Risk questions are not asking which problem sounds scariest. They ask which loss scenario matters most to the business, which vendor or recovery dependency changes impact, and whether the remaining risk has been approved by the right owner.

Exam transformation: wrong options usually appear as accepting vendor risk because the vendor caused the event; patching a visible issue before checking business impact; assuming backups are useful without restore evidence; using vulnerability severity as the only risk score. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Risk register entry	Impact and likelihood scoring	Qualitative, quantitative, or hybrid	Unranked finding	Risk assessment framework	Teams remediate visible issues while higher-impact dependencies remain untreated
Risk appetite statement	Acceptable residual risk boundary	Low, moderate, high, or numeric threshold	Not formally approved	Executive governance	A technical fix is selected without business tolerance alignment
Third-party dependency	Supply chain or subprocessor exposure	Critical, important, low-impact	Unclassified vendor	Contractual obligations and due diligence	Incident scope misses inherited processing or service continuity risk
Backup set	Recoverability and isolation	Connected, disconnected, immutable, tested	Connected and untested	BC/DR testing	Ransomware or deletion propagates into recovery media

Step-by-Step Execution Path

1. Identify the business process, data type, and service dependency affected by the event. This separates vendor outage risk from confidentiality, integrity, and regulatory risk.
2. Review risk appetite and tolerance before selecting treatment. The correct decision must fit the approved residual-risk boundary, not only the most aggressive technical fix.
3. Inspect third-party contracts, subprocessors, notification clauses, data locations, and evidence obligations. This unlocks legal and compliance timing decisions.
4. Validate backup state through restore-test records, isolation status, RPO, and RTO evidence. Connected backups without successful restore evidence are not resilience proof.
5. Document remediation, validation owner, breach response path, and retest date in the risk register. The expected state is traceable treatment with validated recovery evidence.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts with an event or finding, then moves through business impact analysis, third-party obligation review, recovery evidence, risk scoring, treatment selection, and approval. If restore tests fail, availability risk remains high even when backup jobs succeeded. If contract clauses require notification, legal timing becomes part of the security response. The correct exam answer keeps these dependencies together instead of treating vendor, backup, and compliance as separate problems.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate risk priority	Risk register: affected process > impact score > residual risk field	Risk score reflects business impact, likelihood, and approved appetite
Inspect vendor obligations	Third-party risk portal: vendor profile > contract clauses > breach notification	Notification, subprocessor, and audit evidence requirements are visible and current
Confirm recovery evidence	BC/DR repository: restore test report > RPO/RTO result > backup isolation state	Restore test meets target or has documented remediation and retest owner
Check treatment closure	Risk workflow: remediation item > validation evidence > owner approval	Residual risk is accepted, mitigated, transferred, or avoided with approval

Threat Modeling and AI Adoption Security Boundaries

Exam Radar

Official Objective Mapping: Governance, risk, and compliance; related CAS-005 objective areas: threat modeling methodologies, AI risk management, data-flow analysis, trust boundaries, misuse cases, and security requirements for emerging technology adoption.

Plain-English Understanding: This topic tests whether you can model what an AI-enabled system is allowed to see, decide, and do. The main question is not whether AI is risky in general; it is where data crosses a boundary, which identity can invoke tools, and what guardrail proves the assistant cannot exceed its authority.

Key Concepts: data-flow diagram; trust boundary; STRIDE; MITRE ATT&CK / CAPEC; prompt injection; plugin/tool permission; AI data leakage.

Exam Focus: permission boundaries, tool invocation, DLP, audit logging, and misuse-case modeling.

• Core Priority: Model the AI feature as a system with identities, data stores, tools, plugins, prompts, and approval boundaries.
• High Frequency: Stems often describe an assistant that can read sensitive data or trigger actions, then ask which security design step comes first.
• Confusion Alert: Prompt wording is not an enforcement boundary. Real control lives in IAM, DLP, sandboxing, workflow approval, and logging.
• Scenario Logic: Follow the data flow from user prompt to retrieved context, model output, tool call, and downstream action.
• Version Delta: CAS-005 explicitly rewards security thinking around AI adoption, emerging technology risk, and misuse cases.
• Failure Trigger: AI systems fail safely only when tool permissions, sensitive-data access, and audit evidence are bounded outside the model response.
• Operational Dependency: The threat model must identify who can invoke the assistant, what data it can retrieve, which tools it can call, and what logs prove blocked misuse.
• How the Exam Asks It: The question may frame prompt injection, excessive agency, plugin abuse, or sensitive-data summarization as a design review.
• How Distractors Are Designed: Wrong answers focus on model personality, generic risk scoring, or disabling evidence instead of constraining action.
• Why the Correct Answer Works: It turns AI risk into enforceable system controls rather than trusting the assistant to self-police.

Practice Question: An AI assistant can summarize HR records and create help-desk tickets. A test prompt asks it to reveal salary data while opening a privileged workflow. Which control set should be validated first?

A. Data-flow trust boundaries, DLP policy, assistant identity permissions, tool approval gates, and audit logs B. Only the model temperature setting C. Password age for all HR employees D. Whether the assistant has a friendly name

Correct Answer: A

Explanation: A is correct because the scenario combines sensitive-data retrieval and privileged tool action. The defensible response validates the assistant's data boundary, identity permissions, DLP behavior, approval workflow, and audit trail. Temperature, passwords, and display names do not enforce what the assistant may see or do.

Practice Question: A team says prompt injection is solved because the system prompt tells the model to ignore malicious instructions. What is the best response?

A. Accept the claim because system prompts are always authoritative B. Validate least-privilege tool permissions, output filtering, approval workflow, logging, and data access boundaries C. Disable all audit logs D. Give the assistant administrator rights so it can recover from attacks

Correct Answer: B

Explanation: B is correct because prompt instructions can guide behavior but cannot replace enforcement. Least privilege, filtering, approval gates, logging, and data boundaries continue to work even when the model receives hostile input. The other choices either overtrust the prompt or increase blast radius.

Exam Takeaway: For AI scenarios, do not trust prompt wording as a security boundary; choose controls that constrain data access, tool invocation, approval workflow, and audit evidence.

Atomic Deconstruction - Operational Level

What this topic really tests: can you convert an AI feature into a normal security architecture problem with identities, data flows, trust boundaries, permissions, and evidence? Prompt injection matters because the model may be connected to tools, plugins, records, or workflow actions. The control must live where the action is enforced: IAM, DLP, approval workflow, sandbox, content filter, logging, or data boundary. The exam distractor often sounds AI-specific but does not control the underlying permission path.

Beginner-friendly grounding: Think of the AI assistant as a privileged application, not just a chatbot. The risk comes from what it can retrieve, what it can trigger, which identity it uses, and what logs prove blocked misuse.

Exam transformation: wrong options usually appear as treating an AI assistant as only a chatbot UI; using model wording instead of permission boundaries; turning off logs to prevent leakage; ignoring plugin and tool invocation. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Data-flow diagram	Trust boundary crossing	Internal, external, third-party, model-facing	Undocumented flow	Architecture review	Controls are placed at components while data crosses unvalidated boundaries
Threat model	Framework selection	STRIDE, ATT&CK, CAPEC, OWASP, attack trees	Ad hoc brainstorming	Actor and attack-pattern analysis	Important threats are missed because the model does not match the system type
AI assistant identity	Permission boundary	Read-only, delegated, privileged, autonomous	Shared broad service account	IAM and DLP guardrails	Prompt injection or excessive agency causes unauthorized action or data disclosure
Model supply chain	Training, plugin, or dependency integrity	Verified, unverified, poisoned, vulnerable	Unreviewed package or plugin	AI governance and software assurance	Model output or tool execution is trusted without provenance or containment

Step-by-Step Execution Path

1. Draw the current data flow and mark every human, service, third-party, model, and plugin boundary. Trust boundaries show where authentication, authorization, filtering, and logging must be enforced.
2. Select STRIDE for design flaws and ATT&CK or CAPEC for attacker behavior. Framework selection matters because model misuse, social engineering, and plugin abuse appear differently.
3. Inventory AI assistant permissions, delegated scopes, DLP policy, disclosure notices, and tool-action approval states. Excessive agency is controlled by permission boundaries, not by model wording alone.
4. Review model and plugin supply chain evidence, including package provenance, training-data controls, output handling, and sandbox restrictions. This prevents trusting compromised dependencies.
5. Validate controls through scenario rehearsal: prompt injection attempt, sensitive-data retrieval attempt, unauthorized action attempt, and audit-log review. Label this as lab rehearsal unless performed in an official production test process.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts when user input enters an AI application. The prompt is combined with context, retrieved data, tool descriptions, and assistant identity permissions. If a malicious instruction causes the assistant to request restricted data or invoke a tool, enforcement depends on DLP, IAM, plugin approval, sandboxing, and audit logging. A secure design blocks or records the unauthorized path at the boundary; an insecure design trusts the generated text as if it were a policy decision.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Inspect trust boundaries	Architecture review artifact: DFD > boundary annotations > control mapping	Every external, model, and plugin boundary has an authentication, authorization, validation, and logging control
Validate assistant permissions	IAM portal or policy viewer: assistant identity > effective permissions	The assistant has least privilege and no broad write actions without approval workflow
Review DLP guardrails	DLP console: AI app policy > sensitive data rule > enforcement mode	Sensitive records are blocked, redacted, or require justified access according to policy
Rehearse prompt-injection handling	Local lab rehearsal: submit malicious instruction through test tenant and review audit events	The assistant refuses unauthorized tool use and logs the blocked attempt