Master the IT environment, architecture, SDLC, data management, and security principles that underpin all IT risk and control work.
Domain 4 evaluates whether risk professionals understand the IT environment they are managing — technology architecture, SDLC, operations, data management, and core security principles that underpin all IT risk and control work. Expect scenario-based questions requiring you to identify technology risks and select appropriate controls across the full technology stack.
EA frameworks (TOGAF, Zachman) align technology investments with business strategy; technology roadmaps communicate planned changes and associated risks to stakeholders.
Risk must be integrated into every phase of software development — from requirements through retirement. DevOps/Agile introduces speed but also risk of inadequate security testing.
Confidentiality, Integrity, Availability — the three pillars of information security. Frameworks (NIST CSF, ISO 27001, COBIT) provide the control structure for managing security risk.
Privacy by design, data minimization, lawful processing basis, individual rights (access, erasure), breach notification — GDPR and similar regulations create compliance risk that CRISC professionals must assess.
| DR Site Type | Operational State | Data Currency | Activation Time | Cost | RTO Suitability |
|---|---|---|---|---|---|
| Hot | Fully operational, mirrors production | Real-time replication | Minutes | Highest | Very short RTO (critical systems) |
| Warm | Partially configured, systems running | Recent backups (hours old) | Hours | Moderate | Medium RTO (important systems) |
| Cold | Basic infrastructure only (power, network) | Must restore from backup tapes/offsite | Days | Lowest | Long RTO (non-critical systems) |
| Regulation | Scope | Key Requirement | CRISC Relevance |
|---|---|---|---|
| GDPR | EU citizens' personal data, worldwide applicability | 72-hr breach notification; individual rights; DPIAs; lawful basis for processing | High — privacy controls and data risk assessments |
| HIPAA | US healthcare PHI (patients, providers, insurers) | PHI protection; minimum necessary; Business Associate Agreements; breach notification | High in healthcare — controls for PHI access and disclosure |
| CCPA | California residents' personal information | Right to know, delete, opt-out of sale; privacy disclosures at collection | Medium — similar to GDPR for CA-based organizations |
| PCI DSS | Organizations handling cardholder data (payment cards) | 12 requirements covering network security, access, encryption, monitoring, testing | High for retail/financial — control scoping and compliance risk |
Confidentiality (protect from unauthorized access), Integrity (ensure accuracy), Availability (ensure access when needed). Add Non-repudiation (can't deny the action) and you have the full security objective set that underpins every CRISC control discussion. When a question asks about information security objectives, always check whether all four appear — the distractor answer is usually the one that omits non-repudiation.
DR site recovery speed: Hot site (fully mirrored, failover in minutes), Warm site (partially configured, hours to activate), Cold site (basic infrastructure only, days to bring online). Lower RTO = more expensive site. Choose based on BIA-defined RTO. If the BIA says a system must be restored in 4 hours, the answer is NOT a cold site.
The later you find a vulnerability in SDLC, the more expensive it is to fix. Shift security left: threat model in Design, SAST in Development, DAST in Testing. Retirement needs secure data disposal (NIST 800-88). Risk belongs in every phase, not just Testing. On exam questions about when to conduct threat modeling, the answer is always Design — not Testing or Deployment.
In IaaS: provider owns physical/network/hypervisor; you own OS/apps/data. In PaaS: provider adds runtime/middleware; you own apps/data. In SaaS: provider owns almost everything; you still own YOUR DATA and access management. CRISC must assess what you're responsible for. A common wrong answer is assuming the cloud provider is responsible for customer IAM in SaaS — they never are.
Privacy controls must be designed into systems from the start (default privacy settings, data minimization at architecture stage). Adding privacy controls post-deployment is costly and less effective. GDPR's 72-hour breach notification clock starts when the organization becomes aware — not when the breach occurred. This distinction appears frequently in scenario questions.
Every IT change is a risk event. Standard changes: pre-approved, low risk. Normal changes: go through CAB review. Emergency changes: expedited with post-implementation review. Unauthorized changes bypass CAB and are a major control gap — they appear frequently in CRISC audit scenarios. When a question describes a system change that caused an outage, check whether the CAB process was bypassed.
Domain 4 is 20% of CRISC. Expect scenario-based questions testing whether you can identify IT risks within technology topics (cloud, SDLC, DevOps) and know the appropriate control. GDPR/privacy questions appear regularly — know 72-hour notification and key individual rights. Questions on DR site types always require you to map back to BIA-defined RTO, not cost alone. For SDLC questions, the correct action is almost always the earliest phase where the risk could have been addressed.
ISACA CRISC Review Manual Domain 4 (primary source). NIST CSF at nist.gov/cyberframework. ISO/IEC 27001 overview. GDPR full text at gdpr-info.eu. TOGAF overview at opengroup.org/togaf. ISACA Cloud Computing: Business Benefits with Security and Governance. NIST SP 800-88 for data disposal methods.
Map SDLC phases to specific security activities for a fictional web app project. Classify 5 cloud risk scenarios by IaaS/PaaS/SaaS responsibility (who owns the control?). Build a data lifecycle table for a customer database with controls at each phase (Create through Destroy). Practice writing a one-paragraph DPIA summary for a hypothetical new HR system that processes biometric data.
Confusing RTO (restore time) with DR site type selection — hot/warm/cold maps to RTO, not to cost alone. Thinking the cloud provider owns all security (shared responsibility). Missing that GDPR's 72-hour clock runs from when the organization BECOMES AWARE, not when breach occurred. Confusing SAST (static/code analysis, during development) with DAST (dynamic/running application, during testing). Forgetting that unauthorized changes — not just failed ones — are the control gap CRISC flags.
Technology & Security connects to all prior domains: EA changes create new risks for Domain 2 (Risk Assessment). SDLC controls feed Domain 3B (Control Design). Privacy and security frameworks provide the control vocabulary used throughout Domains 1–3. Emerging technologies like AI and cloud are increasingly tested as new risk scenarios. Operations management (change, incident, problem) appears across all domains as the operational risk context.
