Overview
Domain 4 covers the technology and security environment a risk practitioner must understand to identify and judge risk. Part A covers technology principles, roadmaps and enterprise architecture, operations management including change, assets, DevOps, problems and incidents, the system development life cycle, data life cycle management, portfolio and project management, technology resilience and disaster recovery, and emerging technologies. Part B covers security concepts, frameworks and standards, security and risk awareness training, and data privacy and protection principles.
The domain gives the other three their technical substance. Governance decisions in Domain 1 become architecture and policy here. Threats and vulnerabilities assessed in Domain 2 live in these systems and processes. Many of the controls designed and tested in Domain 3 are change, development, backup and data protection controls described here. CRISC expects a manager's understanding of these areas: how each one creates or reduces risk, and what good practice looks like.
How it's tested
Questions describe a technology situation, such as a new system, a failed change, a cloud migration, an AI adoption or a backup gap, and ask what the MOST significant risk is, what should happen FIRST, or what the BEST control is. The exam stays at the level of process and risk, not configuration. The right answer usually ties a technical fact back to a business consequence or a governance step.
-
Process breakdown
A change, incident, development or data process has skipped a step, and you must identify the resulting risk or the missing control.
-
Adopt new technology
The enterprise is adopting cloud, AI or another emerging technology, and you must choose the first or most important risk activity.
-
Right principle, right place
A security or privacy principle, such as least privilege, segregation of duties or data minimization, must be matched to the situation where it applies.
A team wants to deploy a generative AI tool that will process customer support transcripts. Asked what should happen FIRST, set aside answers that buy a monitoring tool or block the project. The tool introduces new data flows and model behavior. The first step is to assess its risk, including privacy, data handling and output reliability, against existing scenarios, appetite and obligations, so the owner can decide on adoption conditions.
Subtopics 11
Official subtopics from the ISACA outline, in outline order.
4.A.1 Technology PrinciplesHow technology components support business processes and where they create risk.
- What it means
- This covers the building blocks of enterprise technology, such as infrastructure, networks, applications, databases and cloud service models (IaaS, PaaS, SaaS), and how they combine to deliver business services.
- What to understand
- Each component and dependency is a potential point of failure or attack, and the practitioner must be able to trace a technical issue to the business process it affects. In cloud services, security responsibilities are shared, and the split depends on the service model.
- How it shows up
- Questions describe a cloud or hybrid environment and ask who is responsible for a given control, or which dependency creates the most risk to a business service.
- Common confusion
- Assuming the cloud provider is responsible for everything. Under SaaS the customer still owns data, identities and access configuration.
4.A.2 Technology Roadmaps and Enterprise Architecture (EA)Planning how technology will evolve in line with business strategy.
- What it means
- Enterprise architecture describes the current and target state of business processes, data, applications and technology, often using frameworks such as TOGAF or Zachman. A technology roadmap plans the transition between those states over time.
- What to understand
- EA helps prevent fragmented, duplicated or unsupported technology. Gaps in it surface as technical debt, unsupported legacy systems and integration risk. Roadmaps should include end-of-life dates so that risk from unsupported technology is planned for, not discovered.
- How it shows up
- A scenario reveals legacy systems past vendor support, or projects that do not fit the target architecture, and you must identify the risk or the governance gap.
- Common confusion
- Viewing EA as documentation for its own sake. Its risk value is in aligning technology decisions with strategy and exposing hidden dependencies.
4.A.3 Operations Management (e.g., change management, assets, DevOps, problems, incidents)Running technology reliably and controlling changes to it.
- What it means
- Change management makes sure changes are requested, assessed, approved, tested, implemented and reviewed, with a way to roll back. Asset management tracks components and configurations. Incident management restores service quickly, and problem management finds and removes the root causes of recurring incidents. DevOps combines development and operations with automated pipelines.
- What to understand
- Unauthorized or untested changes are a leading cause of outages, so even emergency changes need documentation and retrospective approval. In DevOps, controls such as automated testing, peer review, approval gates and logging should be built into the pipeline rather than abandoned for speed.
- How it shows up
- Questions describe repeated outages, an emergency change made without records, or a DevOps team bypassing approvals, and ask for the BEST control or the underlying risk.
- Common confusion
- Treating a closed incident as a solved problem. Restoring service does not remove the root cause, which is problem management's job.
4.A.4 System Development Life Cycle (SDLC)Building risk and security into systems from requirements to retirement.
- What it means
- The SDLC runs through initiation and requirements, design, development, testing, implementation, operation and maintenance, and disposal, in waterfall or iterative forms.
- What to understand
- Risk and security requirements are cheapest and most effective when defined at the start. Key controls include separating development, test and production environments, secure coding and testing, user acceptance, formal approval to go live, and post-implementation review.
- How it shows up
- Questions ask when the risk practitioner should FIRST get involved in a project, usually requirements or initiation, or what risk arises when developers have production access.
- Common confusion
- Treating security testing just before go-live as building security in. By then, design flaws are expensive or impossible to fix.
4.A.5 Data Lifecycle ManagementManaging data from creation to destruction according to its value and obligations.
- What it means
- Data moves through creation or collection, storage, use, sharing, archiving and destruction. Classification determines the handling at each stage, and retention requirements come from legal, regulatory and business needs.
- What to understand
- The data owner decides classification and access, and the custodian carries out handling. Keeping data longer than required increases exposure. Destruction must make data unrecoverable using a method suited to the media, so degaussing does not sanitize solid-state drives.
- How it shows up
- Questions describe data kept indefinitely, shared without classification, or disposed of carelessly, and ask for the MOST significant risk or the right owner of a decision.
- Common confusion
- Mixing up the data owner, accountable for classification and access decisions, with the data custodian, responsible for day-to-day handling and protection.
4.A.6 Portfolio and Project Management (e.g. Agile)Selecting the right technology investments and delivering them with risk in view.
- What it means
- Portfolio management selects and prioritizes investments according to strategy and value. Project management delivers individual initiatives using waterfall or Agile methods. Agile delivers in short iterations with continuous stakeholder feedback.
- What to understand
- Project risk, such as threats to schedule, budget and scope, is different from the IT risk a project's outcome creates for the enterprise. Both need managing. In Agile, risk and security work should be in the backlog and the definition of done, not a separate gate at the end.
- How it shows up
- Questions ask how risk management should fit into Agile delivery, or what the risk is when projects are approved without alignment to strategy.
- Common confusion
- Assuming Agile means no documentation or controls. Agile changes when and how controls are applied, not whether they are.
4.A.7 Technology Resilience and Disaster Response/RecoveryKeeping technology services available and restoring them after disruption.
- What it means
- Resilience uses redundancy, high availability, backups and alternate processing sites (hot, warm or cold) to meet recovery objectives. Disaster recovery plans define how technology is restored and in what order.
- What to understand
- Recovery design must follow the RTO and RPO set through business impact analysis. Backups and DR plans are not proven until they are tested, and test types range from document reviews and tabletop walkthroughs to simulations, parallel tests and full interruption tests.
- How it shows up
- Questions describe a DR plan that has never been tested, backups never restored, or recovery capabilities that do not match business objectives, and ask for the MOST important action.
- Common confusion
- Treating a successful backup job as proof of recoverability. Only a restore test shows the data can be recovered within the RPO and RTO.
4.A.8 Emerging TechnologiesEvaluating new technologies for both risk and opportunity.
- What it means
- This covers technologies such as artificial intelligence and machine learning, Internet of Things devices, distributed ledgers, advanced automation and developments in quantum computing, together with the new risks and benefits each brings.
- What to understand
- The outline asks practitioners to evaluate emerging technologies for threats, vulnerabilities and opportunities. Adoption should be preceded by assessment against appetite and obligations. AI brings specific concerns such as data privacy, bias, output reliability and explainability.
- How it shows up
- A business unit wants to adopt a new technology quickly, and you must choose the first risk activity or the most significant risk.
- Common confusion
- Framing emerging technology only as a threat. The outline explicitly includes opportunities, and blocking adoption is rarely the right answer.
4.B.1 Security Concepts, Frameworks, and StandardsThe core principles and reference models of information security.
- What it means
- Core concepts include confidentiality, integrity and availability, least privilege, need to know, segregation of duties, defense in depth and zero trust. Common frameworks and standards include ISO/IEC 27001 for information security management systems, ISO/IEC 27002 for control guidance, and the NIST Cybersecurity Framework.
- What to understand
- Security principles are applied in proportion to risk, and frameworks are tailored rather than adopted wholesale. ISO/IEC 27001 is a certifiable management-system standard, while ISO/IEC 27002 gives guidance on controls.
- How it shows up
- A scenario shows a principle being violated, such as one person who can create and approve payments, and asks which principle applies or the BEST control.
- Common confusion
- Treating ISO/IEC 27001 certification as proof that every control is effective. It certifies the management system within a defined scope.
4.B.2 Security/Risk Awareness and TrainingBuilding a workforce that recognizes and reports risk.
- What it means
- Awareness programs inform all staff about risks and their responsibilities. Training builds the specific skills each role needs. Both support a risk-aware culture.
- What to understand
- Programs should be role-based, refreshed regularly, and measured by changes in behavior, such as reporting rates and simulated phishing results, rather than completion rates alone. Leadership participation reinforces the message.
- How it shows up
- Questions ask for the BEST measure of an awareness program's effectiveness, or how to tailor training for high-risk roles.
- Common confusion
- Using completion percentage as proof of effectiveness. Completion shows attendance, not changed behavior.
4.B.3 Data Privacy and Data Protection PrinciplesHandling personal data lawfully and protecting data of all kinds.
- What it means
- Privacy principles govern how personal data is collected and used. They include lawful basis, purpose limitation, data minimization, accuracy, storage limitation and accountability. Data protection covers the safeguards used for any sensitive data, such as encryption, masking, tokenization and access control.
- What to understand
- Privacy and security overlap but are not the same. Data can be perfectly secure and still be processed unlawfully. Privacy should be designed in and assessed with privacy impact assessments when processing changes.
- How it shows up
- Questions describe new uses of personal data, data shared with third parties, or data kept beyond its purpose, and ask for the MOST important consideration or the first step.
- Common confusion
- Treating pseudonymized data as anonymous. Pseudonymized data can be re-identified with additional information and generally remains personal data under laws such as the GDPR.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Shared responsibility model
Cloud security duties are split between provider and customer according to the service model.
- Remember
- The customer always keeps responsibility for its data, identities and access decisions.
- Tested as
- Cloud adoption and outsourcing scenarios.
- Trap
- Assuming SaaS means the provider handles everything.
-
Incident vs. problem
Incident management restores service. Problem management removes root causes.
- Remember
- Recurring incidents point to a problem that needs root cause analysis.
- Tested as
- Repeated outage scenarios.
- Trap
- Treating fast incident closure as the fix.
-
Emergency change
A change made urgently to restore or protect service.
- Remember
- It is still recorded and goes through retrospective review and approval.
- Tested as
- Change management breakdown questions.
- Trap
- Accepting undocumented emergency changes.
-
Segregation of environments
Development, test and production are kept separate.
- Remember
- Developers should not have unmonitored write access to production.
- Tested as
- SDLC and SoD questions.
- Trap
- Allowing it for speed in small teams without compensating controls.
-
Security in early SDLC
Risk and security requirements are defined at initiation and requirements stages.
- Remember
- This is the cheapest and most effective point to involve risk.
- Tested as
- When should the practitioner get involved?
- Trap
- Choosing pre-go-live testing as the first involvement.
-
Data owner vs. data custodian
The owner decides classification and access, and the custodian carries out handling and protection.
- Remember
- Ownership sits with the business, and custody usually with IT.
- Tested as
- Data life cycle questions.
- Trap
- Naming IT as the data owner.
-
DR site types
Hot sites are ready almost immediately, warm sites are partly equipped, and cold sites provide space and utilities only.
- Remember
- The choice follows RTO and cost.
- Tested as
- Resilience design questions.
- Trap
- Choosing a hot site where the RTO does not justify the cost.
-
DR test types
Checklist review, tabletop walkthrough, simulation, parallel test and full interruption test.
- Remember
- Full interruption tests give the most assurance and carry the most risk to operations.
- Tested as
- Questions on testing approach.
- Trap
- Choosing full interruption as the first test.
-
Zero trust
No implicit trust is given based on network location. Every access request is verified.
- Remember
- It relies on strong identity, least privilege and continuous verification.
- Tested as
- Architecture and security concept questions.
- Trap
- Treating it as a product rather than an architectural approach.
-
ISO/IEC 27001 vs. 27002
27001 specifies requirements for an information security management system. 27002 gives guidance on controls.
- Remember
- Organizations certify against 27001, not 27002.
- Tested as
- Framework recognition.
- Trap
- Saying an organization is certified to 27002.
-
Data minimization
Collect and keep only the personal data needed for a defined purpose.
- Remember
- It reduces both privacy and breach exposure.
- Tested as
- Privacy scenarios.
- Trap
- Collecting extra data because it might be useful later.
-
Anonymization vs. pseudonymization
Anonymization irreversibly removes the ability to identify a person. Pseudonymization replaces identifiers but can be reversed with extra information.
- Remember
- Pseudonymized data generally remains personal data.
- Tested as
- Data protection questions.
- Trap
- Treating pseudonymized data as outside privacy law.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Incident vs. problem vs. change management
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Incident management | Restoring normal service as quickly as possible | Focuses on speed of recovery, not cause | Thinking closure removes the cause |
| Problem management | Finding and removing root causes of incidents | Focuses on cause and preventing recurrence | Skipping it when incidents keep recurring |
| Change management | Controlling modifications to systems and configurations | Focuses on authorization, testing and rollback | Letting emergency changes go undocumented |
Hot vs. warm vs. cold site
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Hot site | Fully equipped with current systems and data | Fastest recovery and highest cost | Choosing it when the RTO is long |
| Warm site | Partly equipped, needing data and some setup | A balance of cost and recovery speed | Expecting near-immediate recovery |
| Cold site | Space, power and connectivity with no equipment | Lowest cost and slowest recovery | Using it for processes with a short RTO |
IaaS vs. PaaS vs. SaaS responsibility
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| IaaS | The provider supplies infrastructure, and the customer manages operating systems, applications and data | The customer carries the most security responsibility | Assuming the provider patches guest operating systems |
| PaaS | The provider manages the platform, and the customer manages applications and data | Responsibility is shared at the application layer | Neglecting secure coding and configuration |
| SaaS | The provider runs the whole application, and the customer manages use, data and access | The provider carries the most responsibility, but data and identity stay with the customer | Ignoring access configuration and data governance |
Anonymization vs. pseudonymization vs. masking vs. tokenization
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Anonymization | Irreversibly removing identifying information | The data is no longer personal if done properly | Assuming removing names alone anonymizes data |
| Pseudonymization | Replacing identifiers with pseudonyms, with re-identification possible using separate information | Generally remains personal data | Treating it as anonymous |
| Masking | Hiding part of a value, for example showing only the last four digits | Used for display or testing | Assuming masked test data has no privacy risk |
| Tokenization | Substituting a sensitive value with a token mapped in a secure vault | The original value lives only in the vault | Forgetting that the vault becomes a high-value target |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Emergency means no control
- What candidates pick
- Accept an undocumented emergency change because it fixed an outage.
- Why it looks right
- Service was restored, and stopping to document seemed impractical.
- Why it's wrong
- Emergency changes still need recording, retrospective review and approval. Otherwise unauthorized changes hide behind urgency.
Clue to watch for The change is discovered later with no record or approval.
-
Close the incident, move on
- What candidates pick
- Measure success by how fast incidents are closed.
- Why it looks right
- Fast restoration is visible and valued by the business.
- Why it's wrong
- Recurring incidents mean an unresolved root cause. Problem management is needed to stop recurrence.
Clue to watch for The same incident type keeps happening.
-
Security test before go-live
- What candidates pick
- Run a penetration test just before launch as the main security activity.
- Why it looks right
- It is concrete, technical and finds real issues.
- Why it's wrong
- Design-level flaws found at that point are costly to fix. Risk and security requirements should be set at the start.
Clue to watch for The question asks when the practitioner should FIRST be involved.
-
Provider owns it all
- What candidates pick
- Rely on the SaaS provider for access control and data governance.
- Why it looks right
- The provider runs the application and holds certifications.
- Why it's wrong
- Under the shared responsibility model the customer keeps responsibility for its data, users and access configuration.
Clue to watch for The scenario involves misconfigured sharing, excessive user access or data exposure in a SaaS tool.
-
Backups mean recoverable
- What candidates pick
- Accept successful backup job logs as evidence of recoverability.
- Why it looks right
- The jobs complete without errors every night.
- Why it's wrong
- Only restore testing proves that data can be recovered within RTO and RPO.
Clue to watch for No restore test is mentioned.
-
Adopt, then assess
- What candidates pick
- Pilot the new technology widely and assess risk afterwards based on experience.
- Why it looks right
- It is fast and gives real-world data.
- Why it's wrong
- Assessment should come before adoption so the owner can set conditions within appetite and obligations, especially where personal data is involved.
Clue to watch for The scenario involves customer data, AI outputs or regulatory exposure.
-
Completion as effectiveness
- What candidates pick
- Use training completion rate to prove the awareness program works.
- Why it looks right
- It is easy to measure and to report.
- Why it's wrong
- Completion shows attendance. Effectiveness is shown by changed behavior, such as phishing simulation results and reporting rates.
Clue to watch for The question asks for the BEST measure of effectiveness.
Answer framework
When a Domain 4 scenario describes a technology situation, work through these steps before picking an answer.
- Identify which technology process is involved, such as change, incident, development, data handling or recovery, and the business service it supports.
- Find the missing or bypassed step in that process, such as approval, testing, root cause analysis, a restore test or a privacy assessment.
- Determine who is responsible, separating data owners from custodians, providers from customers, and project risk from enterprise risk.
- Translate the technical gap into its business consequence, using recovery objectives, data obligations and appetite as reference points.
- Choose the answer that restores the missing control or assesses the risk before adoption, rather than the most sophisticated technical fix on offer.
Practice question
Want more like this? The CRISC practice test has questions for every domain.
Checklist
0 of 16
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with operations management and the SDLC, because they produce the most scenario questions. Learn the differences between incident, problem and change management, and know where risk and security should enter the development life cycle. Then study data life cycle management together with data privacy and protection principles, since the exam often combines them in one scenario.
Next, cover resilience: DR site types, test types and how RTO and RPO drive design. Connect this to the BIA material from Domain 2 rather than learning it separately.
Candidates commonly underestimate enterprise architecture, portfolio management and emerging technologies, because they feel abstract. For each one, ask what risk appears when it is missing or done badly, such as unsupported legacy systems, misaligned investments or unassessed AI use.
Leave frameworks such as ISO/IEC 27001 and the NIST Cybersecurity Framework for the end, focusing on what each is for.
Afterwards, practice mixed scenarios that combine this domain with Domain 3, because many control design and testing questions are set in the technology processes covered here.
FAQ
How much of the CRISC exam is Domain 4?
Technology and Security is 20% of the exam under the outline effective 3 November 2025, the smallest of the four domains.
How technical is Domain 4?
It requires a manager's understanding of technology processes and security principles, not hands-on configuration skill. Questions focus on risk and process rather than commands or settings.
What is the difference between an incident and a problem?
An incident is a disruption that needs service restored. A problem is the underlying cause of one or more incidents. Incident management restores service, and problem management removes the cause.
Does the exam cover artificial intelligence?
Emerging technologies are an outline subtopic, and AI is a prominent example. Expect questions on assessing new technology for risk and opportunity before adoption, rather than technical AI detail.
Is privacy the same as security?
No. Security protects data from unauthorized access and loss. Privacy governs whether personal data is collected and used lawfully and fairly. Data can be secure and still be misused.
Which security frameworks should I know?
Recognize ISO/IEC 27001 and 27002, the NIST Cybersecurity Framework and COBIT, and understand what each is used for. Clause-level memorization is not the focus.
How does this domain relate to the others?
It supplies the technical context for the rest of the exam. Threats in Domain 2 and controls in Domain 3 live in the processes covered here, and Domain 1's policies are applied through them.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 4 knowledge
You have covered how architecture, operations, development, data and resilience create IT risk, and what good practice looks like. Test whether you can spot the business risk in technology scenarios.