The single most important rule to remember about CCB process: no backout plan = rejected change. This is the fact most commonly tested.
The seven-step CCB workflow in order:
- Scope definition
- Risk analysis
- Implementation plan
- End-user impact assessment
- CCB review and APPROVAL
- Backout plan (required before step 5 can approve)
- Documentation
Exam trap: "A database administrator submitted a change request with a complete implementation plan but no rollback procedure. The CCB approved it anyway." This describes a CCB failure — the CCB should have rejected or tabled the change. The correct answer to "what did the CCB do wrong?" is: approved a change without a documented backout plan.
Also: a backup is NOT a backout plan. A backup recovers data. A backout plan reverses the change step by step.
This is one of the most commonly tested offboarding facts. The question will describe an employee departure and ask what should happen to their account. The answer is always disable, not delete.
Why disable immediately: prevents authentication (security goal achieved on day one).
Why not delete immediately: the account may hold:
- EFS encryption keys (files encrypted by this account are unreadable without it)
- Digital signature certificates (documents signed are unverifiable)
- Service account dependencies (services may fail if the account is deleted)
Correct sequence: Disable day 1 → Review dependencies → Delete after 30-90 days
Exam trap: "The correct offboarding procedure is to delete the account on the last day." This is WRONG. Disable on the last day; delete after dependencies are resolved.
Second trap: "What should happen to a terminated employee's account?" Answer choices often include both "disable" and "delete." Always choose disable.
SOAR and SIEM are frequently confused. Use this distinction:
- SIEM: collects logs, correlates events, generates alerts. It tells you something happened. It does not take action.
- SOAR: receives the alert, executes a playbook, takes action. It does something about it automatically.
Memory phrase: SIEM = Signal. SOAR = Response.
Exam scenario: "When a ransomware alert fires, the system automatically isolates the host, creates a ticket, and queries threat intelligence — all in under 30 seconds." → SOAR. If the question only says "an alert was generated," that is SIEM.
Also remember: SOAR cannot act without playbooks. Playbooks define what SOAR does when triggers fire. A SOAR with no playbooks is an empty automation engine. Playbooks are the "what to do"; SOAR is the "automated how."
Exam trap: Selecting SIEM as the answer when a question describes automated response actions. SIEM detects; SOAR responds.
Governance questions describe a decision-making structure and ask you to classify it. Use this filter: where does authority reside?
- All authority at the center → Centralized governance
- All authority at the edges (business units) → Decentralized governance
- Central sets minimums; edges handle implementation → Federated (hybrid) governance
Most large organizations use federated governance. The exam may describe it as "the CISO sets enterprise-wide policies, and each business unit implements locally" → federated.
Exam trap: "The central security team approves all firewall rule changes across all 20 offices." → Centralized (all approval flows through central). "Each office manages its own firewall with no central oversight." → Decentralized. "Each office manages its own firewall within standards set centrally." → Federated.
Also: regulatory bodies (SEC, GDPR supervisory authorities) are a form of external governance. They impose requirements that shape organizational programs, but they are external governance, not internal organizational governance models.
Practice Scenarios
A systems engineer submits a change request to upgrade the SSL/TLS configuration on all public-facing web servers from TLS 1.0 to TLS 1.3. The request includes: a complete implementation plan with step-by-step commands; a risk analysis noting that some legacy clients using IE 8 may lose connectivity; advance notification to the web team. The request does NOT include a rollback procedure. The CCB is asked to approve it at tomorrow's meeting.
What should the CCB do, and what must be added before approval?
Answer: The CCB should reject or table the change request until a backout plan is documented. The missing element is a rollback procedure that specifies: exactly how to revert the TLS configuration to TLS 1.0 if critical issues arise, what systems/commands are involved, who performs the rollback, and what criteria trigger the rollback decision. The risk analysis (IE 8 client compatibility) is good and represents appropriate awareness. However, it also suggests there IS a risk of impact, making the backout plan even more critical. Additionally, if the risk is loss of IE 8 clients, the CCB should evaluate whether this is acceptable — if not, the change scope may need adjustment (e.g., phased rollout starting with non-critical systems). A complete change request requires scope + risk analysis + implementation plan + user impact + backout plan.
A security team wants to automate their phishing email response playbook using SOAR. Currently, when a phishing alert fires: (1) an analyst manually reviews the email; (2) searches threat intelligence for the sender domain; (3) checks whether the email reached more than 20 users; (4) if yes, escalates to the IR lead; (5) quarantines all matching emails in the mail system; (6) creates an incident ticket.
Which steps can SOAR automate, which require human judgment, and what conditional logic should the automated playbook include?
Answer: SOAR can automate: (2) threat intelligence query — SOAR can call threat intelligence APIs automatically with the sender domain extracted from the alert. (3) email count check — SOAR can query the mail system API to count how many mailboxes received the message. (5) email quarantine — SOAR can call the mail system API to quarantine matching messages automatically. (6) ticket creation — SOAR creates the incident ticket with all collected data automatically. Human judgment required: (1) email review — initial triage still benefits from human confirmation for nuanced cases (legitimate email flagged as phishing). (4) escalation decision — while the condition (>20 users) can be automated, the IR lead should confirm scope and response strategy. Conditional logic: IF threatIntelligence.domainReputation = "malicious" AND emailCount > 20 THEN quarantine AND createTicket AND notifyIRLead. ELSE IF threatIntelligence.domainReputation = "unknown" THEN quarantine AND createTicket AND assignToAnalyst. The automation handles the data gathering and mechanical actions; human judgment handles the ambiguous decisions.
A company is reviewing its HR-IT procedures after two incidents: (A) A new employee was given full administrator access on their first day "to set up their own workstation" — the employee clicked a phishing link on day three and the attacker had domain admin access. (B) A departing employee's account was deleted the day they left; three weeks later, the company discovered that hundreds of client documents encrypted by that employee's EFS certificate were now permanently inaccessible.
What procedure failure caused each incident, and what specific procedure change prevents each?
Answer: (A) Onboarding procedure failure: granting local/domain admin rights during onboarding instead of applying least privilege. Fix: onboarding procedure must specify that all new accounts are created with the minimum permissions required for the job role. Local administrator rights require a separate access request with business justification. Workstation setup should be performed by IT using a standard pre-configured image, not by the user. The phishing click with admin rights gave the attacker domain admin — least privilege would have limited the blast radius to the user's standard account. (B) Offboarding procedure failure: deleting the account on the last day instead of disabling it. Fix: offboarding procedure must specify that accounts are DISABLED (not deleted) on the last day. Before deletion (after a 30-90 day retention period), IT must identify all EFS-encrypted files and resolve the encryption dependencies (either re-encrypting under a recovery agent or exporting the certificate to a secure archive). Account deletion is the last step, not the first.