CISA Complete Review Guide 2026–2027

4. Audit the shared boundary between systems, including how each side interprets exchanged fields, outcomes, and identifiers. ISACA Interface describes the communication boundary, while Middleware describes an intermediary API/service-call layer; successful internal processing on both sides does not prove that their exchange is compatible. For example, compare sender and receiver currency units and reconcile accepted, rejected, and missing records using the organization’s interface requirements.
5. User-built systems and unapproved technology are different dimensions of operational risk. ISACA End-user computing describes users designing and implementing information systems; Shadow IT concerns missing IT/cybersecurity vetting and approval, so an approved business spreadsheet can be end-user computing without being shadow IT. Inventory important user tools, check their approved use and change arrangements, and test enforcement/monitoring of adopted installation policies under NIST CM-11(a)–(c).
6. Measure whether authorized users can access and use information reliably and in time, rather than relying only on server health checks. ISACA Availability and Capacity stress testing support testing representative large data volumes for peak performance; NIST SC-6 distinguishes priority protection from quotas, and CP-2(2) adds contingency processing, telecommunications, and environmental capacity. Inspect actual behavior under contention and degraded support, such as reduced cooling, against the organization’s approved requirements.
7. Track incidents to an understood status and investigate recurring patterns rather than closing each alert when someone acknowledges it. ISACA Problem identifies the unknown underlying cause of one or more incidents; NIST IR-5 supports incident records, status, trends, and handling, while IR-4(c) feeds lessons into procedures, training, and tests. Use the organization’s reportable-incident criteria: the glossary Incident and the NIST IR controls have a security context, so do not silently classify every ordinary service interruption as a security incident.
8. Trace a production change from proposal and security/privacy impact analysis to approval, controlled implementation, and an updated baseline. NIST CM-3(b)–(f), CM-4, and CM-2(b)(3) separate these duties; CM-3(1)(d) does not equate an unanswered request with approval. For patching, SI-2(b)–(d) requires effectiveness/side-effect testing, organization-defined update timing, and configuration-management integration; a vendor installation success alone does not establish acceptable effects on local operations.
9. Follow the log lifecycle: select relevant events, generate sufficient record content, preserve interpretable timestamps, allocate storage, detect logging failures, protect records, review findings, and retain evidence. NIST AU-2, AU-3, AU-4, AU-5, AU-6, AU-8, AU-9, AU-11, and AU-12 address those separate links; AU-7(b) permits useful reduction without changing original content or time ordering. A central console receiving some nodes’ logs is not evidence that a newly added node generates its required events.
10. Translate the SLA into customer-visible targets and agreed measurements, then reconcile reported results to operational evidence. ISACA Service level agreement (SLA) specifies minimum performance targets and how they are measured; an infrastructure-only metric may miss an unavailable business service. For dependent recovery services, NIST CP-7(3) and CP-8(1)(a) align priority provisions with availability/recovery needs, and CP-8(1) guidance warns that other customers may hold similar priority commitments.
11. Distinguish database responsibilities, data organization, update history, and recovery behavior. ISACA DBA/DBMS identify administration and controlling software, Data normalization preserves relationships when organizing tables, and Transaction log records data-file/database updates; login logs and current snapshots are not substitutes for that update history. Database replication copies to replicas for accessibility/reliability, while Rollback reverts to a prior state; verify the actual design before claiming retained history, transaction recovery, or atomic behavior.
12. Start BIA with how loss of supporting resources affects business processes over time, including dependencies and minimum recovery resources. ISACA Business impact analysis (BIA) includes financial, legal, reputational, and interdependent-process impacts; use that analysis to justify recovery priorities rather than ranking applications by equipment price. Recovery time objective (RTO) addresses allowed recovery time, whereas Recovery point objective (RPO) expresses acceptable data loss; evidence for one does not establish the other.
13. Resilience concerns resisting failure or recovering quickly with limited visible effect, while fault tolerance focuses on seamless response to hardware/software failure. ISACA Resilience and Fault tolerance support testing actual service behavior; NIST SI-13 adds environment-specific MTTF and controlled active/standby exchange, and CP-12 defines safe-mode restrictions under specified conditions. Supporting facilities matter too: PE-11 bridges power interruptions, PE-13 uses independent energy for fire protection, PE-14 monitors adopted environmental limits, and PE-15 makes water isolation usable.
14. Distinguish producing a backup, transferring it, protecting it, retrieving it intact, and restoring a usable function. NIST CP-9(a)–(d) covers user/system/documentation backups and protection; CP-9(1) tests retrieval reliability/integrity, CP-9(2) restores selected functions from samples, CP-9(5) addresses transfer, and CP-9(7) requires two qualified individuals for designated destructive actions. CP-9(8) covers cryptographic protection at primary/alternate storage, while CP-10(4) restores from controlled, integrity-protected known-state information within defined time.
15. BCP keeps critical business processes operating during disruption and depends on system recovery arrangements; it may include manual workflows, people, supplies, and external services. ISACA Business continuity plan (BCP) and NIST CP-2(a)(1)–(5), CP-2(5)–(8) connect essential functions, sustained continuity, provider dependencies, and critical technical/operational assets. Coordinate related plans under CP-2(1), train assigned roles under CP-3, and test with related-plan owners under CP-4(1), correcting weaknesses revealed by exercises.
16. DRP organizes human, physical, technical, and procedural recovery resources within defined time and cost; inspect executable restoration arrangements, not just the document title. ISACA Disaster recovery plan (DRP), NIST CP-6/CP-7/CP-8 and their separation, accessibility, preparation, priority, and testing enhancements support that review, including CP-7(6) when return to the primary site is impossible. Under CP-10, reconstitution includes checking fully restored capability, reestablishing monitoring, and deactivating interim capabilities rather than declaring completion after the first successful transaction.

Common mistakes in this chapter

• ✕ A healthy server is not enough evidence of timely information access; test the service outcome required by the SLA.
• ✕ An approved user-built spreadsheet is not automatically shadow IT; approval and authorship answer different questions.
• ✕ Replication may copy an error immediately; verify preserved recovery information rather than assuming replicas provide historical backups.
• ✕ Meeting RTO does not demonstrate RPO: quick restoration can still lose more data than the business permits.
• ✕ Checkpoint restart information is not proof of transaction commit; the glossary Checkpointing term concerns blockchain and is not used for database restart here.
• ✕ Different site addresses, carrier names, or two approving accounts do not prove independent threats or two-person control; test the actual dependencies and individuals.