Domain 4: Information Technology and Security
Arrow keys or space to move, F for full screen. Read the notes
Information Technology and Security
20 topics · Architecture and operations · Projects and development · Data lifecycle · Resilience · Emerging technology · Security principles
D4Enterprise Architecture and IT Risk
How enterprise architecture gives the risk practitioner a map of business processes, data, applications and technology, and how architecture choices and technology roadmaps create or reduce IT risk.
The architecture layers
Why it matters for risk
Roadmaps and transition risk
A technology roadmap moves the organisation from its current architecture to a target state. The destination may be lower risk, but the journey isn't: migrations, parallel systems and skills gaps all create risk along the way.
ExampleA bank's roadmap retired a 20-year-old core system. Architecture mapping found 40 undocumented interfaces depending on it. Each became a migration risk with an owner before cutover planning began.
Architecture governance
- 1Architecture standards approved and maintained.
- 2Projects reviewed against standards at design.
- 3Exceptions risk-assessed and time-limited.
- 4Unsupported systems tracked in the risk register.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Benefit of EA to risk management | Shows dependencies and supports risk-aware decisions |
| Project wants a non-standard technology | Risk-assessed architecture exception |
| Risk of moving to a target architecture | Transition risk must be assessed |
| Unsupported legacy system | Record and manage the risk; plan replacement |
Key takeaways
- ✓Enterprise architecture describes the business, data, application and technology layers and how they connect.
- ✓It shows dependencies, technical debt and single points of failure that drive IT risk.
- ✓Standard, supported technologies reduce complexity and risk; sprawl and unsupported systems increase it.
- ✓Technology roadmaps move from current to target state; the transition itself carries risk.
- ✓Security and risk should be built into architecture decisions, not reviewed afterwards.
Exam traps
- !Treating architecture as an IT-only concern with no business input.
- !Ignoring the risk of the transition between current and target states.
- !Allowing projects to bypass architecture standards without exceptions.
- !Leaving unsupported legacy systems off the risk register.
Change Management Risk
Why uncontrolled change is one of the biggest sources of IT incidents, how a risk-based change process works, and what the risk practitioner looks for in emergency and standard changes.
The change process
Scaling to risk
Emergency changes
ExampleA firm found that 40% of its changes were labelled 'emergency' to skip the CAB. The practitioner reported it as a KRI; the CIO added weekly emergency-change reviews, and the rate fell to 5%.
Risk indicators for change
- 1Changes causing incidents (change failure rate).
- 2Share of emergency changes.
- 3Unauthorised changes detected.
- 4Changes without rollback plans.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| GREATEST change management risk | Unauthorised or untested changes reaching production |
| Emergency change made without approval | Document, test and approve afterwards |
| BEST way to detect unauthorised changes | Compare production with approved changes |
| Who should migrate code to production | Someone other than the developer, or the pipeline |
Key takeaways
- ✓Many outages and security gaps are caused by changes; change management assesses risk before changes go live.
- ✓Changes are requested, assessed, approved, built and tested, migrated by someone other than the developer, and reviewed.
- ✓Scale the process to risk: standard, normal, major and emergency changes.
- ✓Emergency changes can skip prior approval but must be documented, tested and approved afterwards.
- ✓Unauthorised changes are detected by comparing production with approved change records.
Exam traps
- !Developers moving their own code to production.
- !Emergency changes never reviewed afterwards.
- !Treating every change the same regardless of risk.
- !Relying on change tickets to find unauthorised changes.
Assets, Configuration and Dependencies
How IT asset management and configuration management keep an accurate picture of what exists, how it's configured and what depends on it, so risk can be assessed and changes made safely.
Assets and configuration
Asset managementWhat we own or use: hardware, software, licences, cloud services, data.
Configuration managementHow each item is configured and how items depend on each other.
Dependencies
Baselines and drift
- 1Baselines define approved, hardened settings.
- 2Automated tools compare systems with baselines.
- 3Drift is investigated: authorised change or problem?
- 4Baselines are updated through change management.
ExampleImpact analysis for a database upgrade used the CMDB and found a forgotten dependency: the payroll interface. Without it, payroll would have failed on payday.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| MOST useful CMDB feature for risk | Relationships between configuration items |
| How to keep the CMDB accurate | Update it through change management |
| Systems drift from baseline | Investigate; may indicate unauthorised change |
| Purpose of dependency mapping | Impact analysis for changes, incidents and continuity |
Key takeaways
- ✓Asset management tracks what the organisation has; configuration management tracks how it's configured and how items relate.
- ✓A CMDB's value lies in relationships: change one item and you see what depends on it.
- ✓Configuration baselines define approved settings; drift from them is a risk signal.
- ✓Accurate dependency data supports impact analysis, incident response and continuity.
- ✓The CMDB must be updated through change management or it drifts from reality.
Exam traps
- !Treating the asset register as a finance list rather than a risk tool.
- !A CMDB not updated after changes.
- !No baseline, so drift can't be detected.
- !Missing cloud and SaaS assets from the inventory.
Incident and Problem Management Oversight
How incident management restores service and problem management removes root causes, and how the risk practitioner uses incident and problem data to keep risk assessments honest.
Two related processes
What the risk practitioner uses
| Data | Risk use |
|---|---|
| Incident trends | Likelihood estimates; KRIs |
| Root causes | Control weaknesses to address |
| Incidents with no matching scenario | Gaps in the risk register |
| Repeat incidents | Problem management not working |
Oversight questions
- 1Are incidents prioritised by business impact?
- 2Do major incidents get a root cause analysis?
- 3Are known errors tracked to permanent fixes?
- 4Does incident data feed the risk register?
ExampleThe service desk logged 300 similar VPN failures in a quarter, each closed with a reboot. The practitioner flagged it as a risk; problem management found a capacity limit and a permanent fix ended the incidents.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Recurring incidents of the same type | Problem management needed |
| How to prioritise incidents | Business impact and urgency |
| Incident not matching any scenario | Update risk identification |
| Value of incident data to risk | Evidence for likelihood and control effectiveness |
Key takeaways
- ✓Incident management restores service quickly; problem management finds and removes root causes.
- ✓Incidents should be prioritised by business impact and urgency.
- ✓Recurring incidents point to weak problem management.
- ✓Incident and problem data are evidence for risk assessments, KRIs and control effectiveness.
- ✓Incidents not covered by any risk scenario reveal gaps in risk identification.
Exam traps
- !Closing incidents repeatedly without addressing root causes.
- !Prioritising incidents by who reported them.
- !Keeping incident data away from the risk function.
- !Treating a low number of reported incidents as proof of low risk.
Project Governance and IT Risk
The risks IT projects carry, both to their own delivery and to the operations they change, and how project governance and risk checkpoints keep them visible and owned.
What can go wrong
Risk at each gate
The triple constraint
ExampleTo hit a launch date, a project quietly removed audit logging from scope. The practitioner raised it with the sponsor, who formally accepted a three-month gap with compensating monitoring rather than discover it later in an audit.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST time to assess project risk | At initiation and each gate |
| Who owns the business case and benefits | The project sponsor |
| Project drops a control to meet a deadline | Formal risk decision by the right owner |
| Risks remaining after go-live | Transfer to the operational risk register |
Key takeaways
- ✓IT projects carry delivery risk (late, over budget, benefits missed) and leave operational risk when they go live.
- ✓Project governance assigns a sponsor who owns the business case and benefits.
- ✓Risk checkpoints at project gates catch risks while they're cheap to fix.
- ✓Scope, time and cost are linked; squeezing all three reduces quality and controls.
- ✓Project risks should feed the enterprise risk register, especially those that remain after go-live.
Exam traps
- !Assessing security and control risk only at go-live.
- !Letting the project team accept operational risks beyond its authority.
- !Dropping control requirements to meet a deadline without a formal decision.
- !Keeping project risks in a separate log that never reaches the enterprise register.
Governing the Secure SDLC
How security and control requirements are built into each stage of the system development life cycle, and the governance that makes sure they don't get dropped.
Security at every stage
Earlier is cheaper
Governance that works
- 1Secure development standards approved and trained.
- 2Security requirements in every specification.
- 3Gates with defined security evidence.
- 4Independent review before release.
- 5Software bill of materials for components.
ExampleA security flaw found in production cost 30 times more to fix than the same flaw would have cost at design. After the review, threat modelling became a mandatory design gate for all customer-facing systems.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| MOST cost-effective time to add security | Requirements and design |
| BEST way to ensure security isn't dropped | Defined gates with evidence |
| Open-source components | Inventory and scan them (SBOM) |
| Who approves code for release | Someone independent of the developer |
Key takeaways
- ✓Security built in during requirements and design costs far less than security added after release.
- ✓Each SDLC stage has security activities: requirements, threat modelling, secure coding, testing and release sign-off.
- ✓Application controls (input, processing, output) are defined as requirements, not afterthoughts.
- ✓Governance means defined standards, gates and evidence, not just good intentions.
- ✓Third-party and open-source components need the same scrutiny as in-house code.
Exam traps
- !Penetration testing just before go-live as the only security activity.
- !No security requirements in the original specification.
- !Ignoring open-source and third-party libraries.
- !Developers approving their own code for release.
DevOps, CI/CD and Agile Delivery Risk
How fast, frequent delivery changes IT risk, and how agile and DevOps teams keep controls such as segregation of duties, testing and approval working inside the pipeline.
Controls move into the workflow
Segregation of duties in DevOps
Protecting the pipeline
- 1Restrict who can change pipeline configuration.
- 2Log and review pipeline changes.
- 3Protect secrets and signing keys used by the pipeline.
- 4Scan code, dependencies and containers automatically.
ExampleAn attacker who compromised a developer's account changed a pipeline script to add a backdoor to every build. Requiring approval for pipeline changes and signing build artefacts closed the gap.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| SoD in CI/CD | Peer review and pipeline-only deployment |
| Security in agile | Backlog items and definition of done |
| GREATEST DevOps risk | Unreviewed changes reaching production, or an unprotected pipeline |
| Keeping security pace with releases | Automated testing in the pipeline |
Key takeaways
- ✓Agile and DevOps deliver small changes often; controls must be built into the way teams work.
- ✓Security and control requirements go into the backlog and the definition of done.
- ✓In CI/CD, segregation of duties is enforced by peer review, protected branches and pipeline-only deployment.
- ✓The pipeline itself is a critical asset; changes to it must be restricted and logged.
- ✓Automated testing and scanning keep pace with frequent releases.
Exam traps
- !Assuming agile means no documentation or controls.
- !Developers self-approving merges and deploying with personal credentials.
- !Leaving the pipeline open for anyone to edit.
- !Manual security reviews that can't keep up with release frequency.
Testing, Release and Deployment Risk
How testing levels, release management and go-live decisions control the risk of putting new or changed systems into production, including data conversion and rollback.
Levels of testing
Controlled release
The go/no-go decision
ExampleTwo days before go-live, four critical defects were still open. Instead of the project manager deciding, the practitioner made sure the business owner saw the residual risk; go-live was delayed a week and the defects fixed.
Test data
- 1Use masked or synthetic data where possible.
- 2Protect test environments if real data is unavoidable.
- 3Remove test accounts before go-live.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who accepts a system for production | The business owner |
| Critical defects before go-live | Business owner decides with full knowledge |
| Essential for a major release | A tested rollback plan |
| Production data in testing | Mask it or protect it equally |
Key takeaways
- ✓Testing moves from unit to integration, system and user acceptance testing, each checking something bigger.
- ✓Users or business owners formally accept a system before go-live.
- ✓Release management moves tested changes into production in a controlled way, with a tested rollback.
- ✓Go/no-go decisions rest with the business owner, based on test results and residual risk.
- ✓Data conversion must be reconciled and signed off by data owners.
Exam traps
- !Developers testing and accepting their own work.
- !Going live with critical defects open and no formal risk decision.
- !No rollback plan for a major release.
- !Using unmasked production data in test environments.
Data Classification, Ownership and Handling
How data is classified by sensitivity, who decides the classification, and how clear handling rules for each level turn classification into everyday protection.
Classification levels
Who does what
Handling rules
ExampleStaff labelled 80% of documents 'restricted' to be safe. Restricted handling became impossible to follow, so people ignored it. Simplifying to four levels with clear examples brought restricted down to 5% and compliance up.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who classifies data | The data owner |
| MAIN benefit of classification | Protection matched to value |
| Result of over-classification | Wasted cost and ignored labels |
| Classification without handling rules | Ineffective; define rules for each level |
Key takeaways
- ✓Classification matches protection to the value and sensitivity of data.
- ✓Data owners, who are business managers, set classification; custodians implement the controls; users follow the rules.
- ✓Three to five levels is typical; too many confuses people.
- ✓Each level needs clear handling rules for storage, sharing and disposal.
- ✓Classification is reviewed as data's sensitivity changes.
Exam traps
- !Letting IT classify business data.
- !Over-classifying everything, which makes labels meaningless.
- !Classification levels with no handling rules.
- !Never reviewing classifications after events such as public announcements.
Data Lifecycle: Integrity, Retention and Disposal
How data is protected from creation to destruction: keeping it accurate and complete, retaining it as long as the law and business require, and disposing of it securely.
The data life cycle
Integrity
- 1Input validation and edit checks.
- 2Reconciliations between systems.
- 3Access control and segregation of duties.
- 4Change control over data and programs.
- 5Integrity checks on archives and backups.
Retention
ExampleA company kept every email since 2005. A lawsuit required it to search and disclose 15 years of mail at great cost, and a later breach exposed old customer data it had no reason to keep. A retention schedule fixed both risks.
Secure disposal
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Basis for retention periods | Legal, regulatory and business requirements |
| Litigation expected | Apply a legal hold |
| Risk of keeping data too long | Higher breach and legal exposure |
| Disposal of SSDs or cloud data | Crypto-erase or physical destruction |
Key takeaways
- ✓Protection follows data through creation, storage, use, sharing, archiving and destruction.
- ✓Data integrity controls keep data accurate, complete and unaltered: validation, reconciliation and access control.
- ✓Retention schedules come from legal, regulatory, contractual and business requirements.
- ✓Keeping data too long increases breach and legal exposure; legal holds suspend deletion when litigation is expected.
- ✓Secure disposal must match the media and sensitivity, with evidence of destruction.
Exam traps
- !Keeping all data forever 'just in case'.
- !Deleting data covered by a legal hold.
- !Treating file deletion or formatting as secure disposal.
- !Forgetting data held by suppliers and in backups.
Business Continuity Planning and Governance
How business continuity planning keeps critical processes running through disruption, from the BIA to strategies, plans, training and maintenance, and how it links to IT risk management.
The BCP life cycle
BCP and DRP
Strategies for each kind of loss
Governance
- 1Senior management sponsors and approves the program.
- 2Business owners own their process plans.
- 3Continuity risks appear in the risk register.
- 4Tests and lessons feed back into plans.
ExampleA regional bank's continuity plan covered IT failover well, but the BIA had never considered loss of its single cash-handling supplier. When that supplier failed, branches ran short for a week. Supplier continuity became a top-ten risk.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| FIRST step after management commitment | Business impact analysis |
| Who owns business continuity | Senior management and business owners |
| Relationship between BCP and DRP | DRP is part of BCP |
| Plan not updated after reorganisation | Significant weakness; update and retest |
Key takeaways
- ✓Business continuity keeps critical business processes running; disaster recovery restores IT within it.
- ✓After management commitment, the BIA comes first and drives recovery objectives and strategies.
- ✓Strategies cover loss of site, IT, people and suppliers, not only technology.
- ✓Plans must be trained, tested and maintained after every significant change.
- ✓Senior management owns continuity; the risk practitioner links it to the risk profile and appetite.
Exam traps
- !Treating continuity as an IT-only project.
- !Writing strategies before completing the BIA.
- !Plans that cover technology but forget people and suppliers.
- !Plans never updated after organisational change.
Disaster Recovery and Testing Recovery Capability
How recovery objectives drive the choice of recovery sites and backup strategies, and how progressively realistic testing proves the organisation can actually recover.
Objectives drive the solution
Recovery sites
Testing recovery
ExampleA DR test brought the core application up in two hours, but staff couldn't log in: the identity service only existed at the primary site. The plan was updated to recover identity first, and the next test passed.
What a good test proves
- 1Objectives (RTO, RPO) were met.
- 2People knew their roles.
- 3Dependencies came up in the right order.
- 4Data was complete and consistent.
- 5Issues were logged and fixed.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| What drives recovery site choice | RTO and RPO from the BIA |
| MOST significant DR weakness | Plan not tested |
| Least disruptive test | Checklist review or walkthrough |
| Test reveals problems | Useful result; fix and retest |
Key takeaways
- ✓RTO decides how fast systems must return; RPO decides how much data loss is acceptable.
- ✓Faster recovery costs more; recovery options should match objectives from the BIA.
- ✓Recovery sites range from mirrored and hot to warm and cold; cloud DR can play any of these roles.
- ✓Tests progress from checklist and walkthrough to simulation, parallel and full interruption.
- ✓An untested plan can't be relied on; test results and fixes feed back into the plan.
Exam traps
- !Choosing a recovery site before setting RTO and RPO.
- !Assuming backups work without restore testing.
- !Running a full interruption test before simpler tests have succeeded.
- !Forgetting dependencies such as identity, DNS and network at the recovery site.
Emerging Technology Risk: Cloud, IoT and OT
The characteristic risks of cloud, IoT, operational technology and other emerging technologies, and how the risk practitioner assesses them before and after adoption.
Technologies and their risks
Cloud shared responsibility
Assessing before adoption
- 1What business need does it serve?
- 2What data and processes will it touch?
- 3What new threats and dependencies does it bring?
- 4Do we have the skills to run it securely?
- 5Is the risk within appetite, and who owns it?
ExampleA manufacturer planned to connect plant controllers to the cloud for analytics. The risk assessment showed a compromise could stop production lines. The design was changed to a one-way data flow from OT to the cloud.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| MOST common cause of cloud breaches | Customer misconfiguration |
| Main concern when connecting OT to IT | Physical and safety impact |
| BEST control for IoT devices | Inventory and network segmentation |
| FIRST step with a new technology | Assess the risk before adoption |
Key takeaways
- ✓Every new technology brings opportunity and characteristic risks; assess them before adoption.
- ✓Cloud risk centres on shared responsibility, misconfiguration and concentration.
- ✓IoT devices are often weak, hard to patch and numerous; inventory and segment them.
- ✓Operational technology failures can cause physical and safety harm; changes need special care.
- ✓Quantum computing is a future threat to public-key cryptography; planning starts with a crypto inventory.
Exam traps
- !Assuming the cloud provider handles all security.
- !Connecting OT systems to corporate networks without assessing safety impact.
- !Letting IoT devices onto the network without inventory or segmentation.
- !Ignoring long-term risks such as quantum because they seem distant.
AI and Machine Learning Risk
The risks of using and building artificial intelligence, from data leakage and inaccurate output to bias, misuse and regulation, and how to govern AI like any other risk.
What can go wrong
Governing AI
Risks and controls
ExampleA lender's AI model began rejecting more applicants from certain postcodes. Monitoring of outcomes across groups caught it within a month; the model was retrained, and decisions above a threshold now get human review.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| FIRST step in governing AI use | Inventory AI uses and assign owners |
| Staff using public AI tools with company data | Assess the risk; provide approved options |
| Risk specific to machine learning | Bias, drift, poisoned training data |
| High-impact AI decisions | Human oversight and outcome testing |
Key takeaways
- ✓AI brings familiar risks (data leakage, third parties) and new ones (unreliable output, bias, prompt injection, model drift).
- ✓Govern AI with a policy, an inventory of uses, risk assessment, approval with controls and monitoring.
- ✓High-impact AI decisions need human oversight and testing for accuracy and fairness.
- ✓Shadow AI, staff using unapproved tools with company data, is a common early risk.
- ✓Regulation such as the EU AI Act sets obligations by risk level.
Exam traps
- !Banning AI outright, which pushes use underground.
- !Approving AI tools without checking what happens to the data entered.
- !Assuming AI output is accurate without testing or review.
- !Treating AI as purely a technology issue rather than a business, legal and ethical one.
Setting Risk Boundaries for Innovation
How the risk practitioner helps the business innovate safely, using appetite, guardrails, sandboxes and pilots instead of blanket bans or uncontrolled adoption.
Enable, don't block
Organisations that refuse all new technology lose ground to competitors; those that adopt it blindly suffer avoidable losses. The risk practitioner's job is to make safe experimentation possible within the appetite the board has set.
Guardrails in practice
Typical boundaries
| Boundary | Example |
|---|---|
| Data | No customer or personal data in the pilot |
| Users | 50 internal users only |
| Time | 90-day trial, then decide |
| Spend | Capped budget |
| Integration | No connection to production systems |
ExampleA retailer wanted to test an AI chatbot for customer service. Guardrails limited it to answering product questions with no access to orders or accounts. After a successful pilot, full controls were added before it handled customer data.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST approach to a promising but risky technology | Pilot with defined guardrails |
| Pilot becomes production | Apply full controls first |
| Data in a sandbox | No production or sensitive data |
| Role of risk management in innovation | Enable within appetite |
Key takeaways
- ✓Risk management should enable innovation within appetite, not block it.
- ✓Guardrails define what data, users, spend and time a new initiative may use.
- ✓Sandboxes and pilots let the business learn while limiting the impact of failure.
- ✓Full controls are required before an innovation scales to production.
- ✓Each innovation needs an owner who accepts its risk.
Exam traps
- !Banning new technology because its risks aren't fully known.
- !Letting pilots quietly become production systems without controls.
- !Using production data in sandboxes.
- !Innovation projects with no risk owner.
Core Security Concepts: CIA, IAM, Cryptography and Network Security
The security concepts a risk practitioner needs to discuss controls with confidence: confidentiality, integrity and availability, identity and access management, cryptography, and network and endpoint protection.
Security objectives
Identity and access
Cryptography in brief
Network and endpoint
Zero trust
ExampleAn attacker who phished one employee moved freely across a flat network to the finance servers. Under a zero trust design, the stolen session would have reached only the applications that employee needed, and unusual access would have been challenged.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Control proving data wasn't altered | Hashing or digital signature |
| MOST important control for remote access | Multi-factor authentication |
| Limits spread of an attack | Segmentation or zero trust |
| Weakest part of most encryption | Key management |
Key takeaways
- ✓Confidentiality, integrity and availability are the core security objectives; accountability and non-repudiation extend them.
- ✓Identity and access management covers the identity life cycle, authentication, authorisation, privileged access and reviews.
- ✓Symmetric encryption protects bulk data, asymmetric encryption solves key exchange and signatures, and hashing proves integrity.
- ✓Network and endpoint controls (segmentation, firewalls, EDR, hardening) limit how attacks spread.
- ✓Zero trust replaces trust based on network location with verification of every request.
- ✓Defence in depth layers controls so one failure doesn't expose the asset.
Exam traps
- !Thinking hashing provides confidentiality.
- !Relying on the network perimeter alone.
- !Treating MFA as optional for privileged and remote access.
- !Assuming encryption is strong when keys are poorly managed.
Security Frameworks and Control Standards
How security frameworks such as NIST CSF, ISO 27001 and the CIS Controls give structure to a security program, and how policies, standards and baselines turn them into enforced controls.
NIST CSF 2.0
From framework to enforcement
Choosing and using frameworks
| Framework | Use |
|---|---|
| ISO/IEC 27001 | Certifiable management system |
| NIST CSF 2.0 | Outcome-based structure and maturity view |
| CIS Controls | Prioritised practical safeguards |
| NIST SP 800-53 / ISO 27002 | Detailed control catalogues |
ExampleA company adopted NIST CSF and reported 'Protect: tier 3' to the board. Testing found MFA covered only 60% of remote users. The standard existed, but nobody monitored compliance; adding a KCI closed the gap within a quarter.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Function added in NIST CSF 2.0 | Govern |
| Certifiable security standard | ISO/IEC 27001 |
| Where specific security settings belong | Standards and baselines |
| Evidence standards are followed | Monitoring and control testing |
Key takeaways
- ✓Security frameworks give a structure for organising and measuring security controls.
- ✓NIST CSF 2.0 organises security into Govern, Identify, Protect, Detect, Respond and Recover.
- ✓ISO/IEC 27001 is certifiable; ISO 27002, NIST SP 800-53 and CIS Controls provide control detail.
- ✓Policies, standards and baselines make framework requirements specific and enforceable.
- ✓Monitoring, exceptions and metrics show whether standards are actually followed.
Exam traps
- !Adopting a framework without tailoring it to risk.
- !Assuming framework adoption means controls are effective.
- !Standards that exist on paper with no monitoring.
- !Confusing ISO 27001 (certifiable) with ISO 27002 (guidance).
Security Awareness Culture and Measuring Training
How security awareness and training reduce people-related risk, how to tailor them by role, and how to measure whether behaviour actually changes.
Why awareness matters
Phishing, misdirected emails, weak passwords and approving fake payments are human actions. Technical controls help, but people who recognise and report risk are a control in their own right.
Building the program
Measuring what matters
ExampleTraining completion was 100% for two years, but the phishing click rate stayed at 25%. Shorter monthly simulations with instant feedback, plus a one-click report button, cut clicks to 6% and doubled reporting.
Targeting high-risk roles
- 1Finance: payment fraud and supplier impersonation.
- 2Administrators: privileged access and social engineering.
- 3Executives: whaling and confidentiality.
- 4Developers: secure coding.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST measure of awareness effectiveness | Behaviour change, such as fewer phishing clicks |
| Weakness of completion rates | Show activity, not effect |
| Group needing targeted training | High-risk roles such as finance and admins |
| Improve incident reporting | No-blame culture and simple reporting |
Key takeaways
- ✓Many incidents start with human action; awareness reduces the likelihood of people-caused risk events.
- ✓Effective programs are continuous, relevant, role-based and supported by leaders.
- ✓High-risk roles such as finance, administrators and executives need targeted training.
- ✓Measure behaviour (phishing click and report rates, user-caused incidents), not just completion.
- ✓A no-blame reporting culture is as important as training content.
Exam traps
- !Measuring success by training completion rates.
- !One annual session for everyone.
- !Punishing people who report mistakes.
- !Ignoring executives and privileged users.
Privacy Governance and Data Protection Principles
How privacy differs from security, the core data protection principles, and how a privacy program manages the risk of collecting, using and keeping personal data.
Privacy versus security
Data protection principles
The privacy program
ExampleA new marketing app was ready to launch, collecting location data every five minutes. A late privacy impact assessment found no lawful basis for continuous tracking. Redesigning it cost three months; an assessment at design would have cost a week.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Collecting more data than needed | Breaches data minimisation |
| When to do a privacy impact assessment | During design, before processing starts |
| Relationship between privacy and security | Security is necessary but not sufficient |
| Who is accountable for personal data | The controller (the organisation) |
Key takeaways
- ✓Security protects data; privacy asks whether the organisation should collect and use it at all, and how.
- ✓Core principles include lawfulness, purpose limitation, minimisation, accuracy, storage limitation, security and accountability.
- ✓A privacy program covers records of processing, notices, impact assessments, individuals' rights, processors and breach response.
- ✓Privacy impact assessments are done before high-risk processing starts.
- ✓Privacy risk is a business risk with legal, financial and reputational impact.
Exam traps
- !Assuming strong security means privacy obligations are met.
- !Collecting data 'in case it's useful later'.
- !Doing a privacy impact assessment after launch.
- !Forgetting processors and cross-border transfers.
Developing a Data Protection Control Strategy
How to build a data protection strategy that finds sensitive data wherever it lives, protects it in proportion to its value, and monitors and responds when it's at risk.
The strategy step by step
Choosing controls
| Control | Protects against |
|---|---|
| Encryption (at rest, in transit) | Disclosure if media or traffic is intercepted |
| Access control and least privilege | Unauthorised internal access |
| DLP | Sensitive data leaving through email, web, USB |
| Masking and tokenisation | Exposure in test, analytics or payments |
| Backup and immutability | Loss and ransomware |
Don't forget copies
- 1Test and development environments.
- 2Analytics and data lakes.
- 3Suppliers and processors.
- 4Backups and archives.
- 5Personal devices and cloud drives.
ExampleA firm encrypted its production customer database but copied it unmasked into an analytics platform with 200 users. A data discovery scan found it, and masking was applied before the next quarterly copy.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| FIRST step in a data protection strategy | Discover and classify sensitive data |
| Protect data used in testing | Masking or synthetic data |
| Stop sensitive data leaving by email | DLP |
| Basis for control strength | Data classification |
Key takeaways
- ✓A data protection strategy starts with discovering where sensitive data is, including SaaS and shadow IT.
- ✓Owners classify data; controls are applied in proportion to classification.
- ✓Key controls include encryption, access control, DLP, masking, tokenisation and backup.
- ✓Monitoring detects unusual access and movement; response plans handle breaches.
- ✓The strategy is reviewed as data, regulation and threats change.
Exam traps
- !Buying a DLP tool before knowing where sensitive data is.
- !Encrypting everything equally regardless of value.
- !Ignoring data held by suppliers.
- !Protecting production data while leaving copies in test and analytics environments.
1 / 150