CRISC — Frequently Asked Questions

The control owner should first reassess and update the control objectives and control activities to align with the new organizational structure. After restructuring, roles, responsibilities, and reporting lines may have changed, so the control owner must review the RACI matrix (Responsible, Accountable, Consulted, Informed) to ensure that accountability for each control is clearly assigned to the appropriate individuals or teams. This includes verifying that control owners are still in the correct positions, that segregation of duties is maintained, and that any gaps in control ownership are identified and addressed. Only after confirming the updated ownership structure should the control owner proceed with testing and validating control effectiveness.

A modified disaster recovery plan (DRP) must be tested after any significant change to ensure that the modifications have not introduced new vulnerabilities or broken existing recovery procedures. Changes to IT infrastructure, applications, business processes, or personnel can affect recovery time objectives (RTO) and recovery point objectives (RPO). Testing validates that the updated plan can successfully restore critical business functions within acceptable timeframes and data loss thresholds. Without testing, organizations risk discovering during an actual disaster that the modified plan fails to work, leading to extended downtime, data loss, and potential business failure. ISACA recommends testing DRPs at least annually and after any major system or process changes.

Threat assessment and threat modeling processes determine threat relevance for risk scenarios. In CRISC, this is part of Domain 2 (IT Risk Assessment), where threat intelligence is analyzed to determine which threats are relevant to specific assets, business processes, and risk scenarios. The process involves identifying potential threat actors, their motivations, capabilities, and likely targets, then mapping those threats to organizational assets and processes. This helps prioritize which threats pose the greatest risk based on likelihood and potential impact. The output feeds into the risk register and informs risk response decisions. Key frameworks like NIST SP 800-30 and ISO 27005 provide structured approaches for conducting threat assessments that determine threat relevance.

The best way to prove that implemented controls reduce IT risk is through control testing and effectiveness evaluation, which includes both design testing (checking if the control is properly designed to address the risk) and operating effectiveness testing (verifying the control operates as intended over time). Key evidence includes: (1) Test results showing the control consistently operates as designed, (2) Key Risk Indicators (KRIs) demonstrating risk reduction trends, (3) Audit reports and findings, (4) Metrics comparing residual risk levels before and after control implementation, and (5) Exception reports showing the number and severity of control failures. The most compelling evidence combines quantitative metrics (e.g., percentage reduction in incidents) with qualitative assessments from independent audits.

Risk sharing (also known as risk sharing or risk pooling) occurs when an organization collaborates with another entity to jointly manage and distribute risk exposure. A classic CRISC example is when a company enters into a business continuity partnership with another organization, where each agrees to support the other's critical operations during a disaster. Another example is outsourcing non-core functions to a third-party provider with defined service level agreements (SLAs) and shared responsibility clauses. In cloud computing, risk sharing is evident in the shared responsibility model where the cloud provider secures the infrastructure while the customer secures their data and applications. Risk sharing differs from risk transfer (insurance) and risk mitigation (implementing controls) — it specifically involves distributing risk exposure across multiple parties.

Information no longer required by business objectives should be securely disposed of or archived according to the organization's data retention and disposal policies. This is a critical part of data lifecycle management in CRISC Domain 4. The process involves: (1) Identifying the data category and classification level, (2) Verifying legal, regulatory, and contractual retention requirements, (3) Applying secure disposal methods appropriate to the data sensitivity (e.g., cryptographic erasure for digital data, physical destruction for media), (4) Documenting the disposal action in an audit trail, and (5) Obtaining proper authorization from the data owner. Improper retention of unnecessary data increases the organization's attack surface, compliance risk, and potential liability in the event of a data breach.

The best approach to assess identified risk events in projects is to conduct a qualitative (and when necessary, quantitative) risk analysis that evaluates each risk event based on its probability of occurrence and potential impact on project objectives (scope, time, cost, quality). The process involves: (1) Scoring each risk event on a probability-impact matrix, (2) Prioritizing risks based on their combined score, (3) Identifying the most critical risks requiring immediate response, (4) Assigning risk owners for each significant risk, and (5) Developing risk response plans for high-priority risks. This should be done in collaboration with key project stakeholders and updated regularly throughout the project lifecycle. The output feeds into the project risk register and informs decision-making about resource allocation for risk mitigation.

The best way to validate control implementation is through a combination of inquiry, observation, inspection of documentation, and re-performance (re-execution) of the control. Re-performance is considered the most reliable method because it involves independently executing the control to verify it produces the expected result. The validation process should: (1) Confirm the control is designed appropriately to address the identified risk, (2) Verify the control is operating as designed through testing, (3) Check that the control operates consistently over a representative period, (4) Evaluate the competence and objectivity of personnel performing the control, and (5) Document findings and any exceptions. ISACA emphasizes that validation should go beyond checking if a control exists on paper — it must confirm the control actually works in practice.

The best KPI for measuring uninterrupted IT service delivery is system availability (or service availability), typically expressed as a percentage of uptime over a given period (e.g., 99.9% availability). This metric directly measures whether IT services are operational and accessible to users when needed. Other complementary KPIs include: Mean Time Between Failures (MTBF), which measures reliability; Mean Time to Recover (MTTR), which measures recovery speed; and service level achievement rate, which compares actual performance against SLA targets. Availability is preferred as the primary KPI because it provides a clear, quantifiable measure of service continuity that directly correlates with business impact. It should be monitored continuously and reported against defined service level agreements.

Business stakeholders for IT risk scenarios should be identified through a systematic process that maps business processes to their supporting IT systems and then identifies the individuals or groups responsible for those processes. Key steps include: (1) Reviewing the organizational chart and RACI matrix to identify process owners and business unit leaders, (2) Conducting interviews and workshops with department heads to understand their critical processes and dependencies on IT, (3) Analyzing business impact analysis (BIA) results to identify which roles are affected by IT disruptions, (4) Reviewing governance frameworks and approval matrices, and (5) Engaging with compliance and legal teams for regulatory-related stakeholders. The goal is to ensure all parties with authority, accountability, or significant interest in specific business processes are included in risk scenario discussions and decision-making.

During a cloud-to-on-premises migration, a risk practitioner should first conduct a comprehensive risk assessment that identifies and evaluates the unique risks introduced by the migration. This includes: (1) Performing a pre-migration audit of all on-premises applications, data, and user access policies, (2) Identifying sensitive data that requires special handling (e.g., PII, financial data) and ensuring compliance with regulations like GDPR or HIPAA, (3) Evaluating third-party integrations and dependencies for security gaps, (4) Assessing the security posture of the target on-premises environment, and (5) Identifying configuration and compliance risks. The risk assessment should be completed before migration begins to ensure that appropriate controls are in place and that the organization understands the risk landscape of the post-migration environment. This aligns with CRISC Domain 2 (IT Risk Assessment) and Domain 3 (Risk Response).

To predict business impact probability from cooling failures, a risk practitioner should conduct a failure mode and effects analysis (FMEA) combined with historical data analysis and environmental risk assessment. The process involves: (1) Identifying all systems and processes dependent on cooling infrastructure, (2) Analyzing historical cooling failure data to determine frequency and duration, (3) Evaluating the effectiveness of current cooling controls and backup systems (e.g., redundant HVAC, UPS, generators), (4) Modeling worst-case scenarios where cooling fails during peak load conditions, and (5) Estimating the probability of cooling failure leading to system downtime and quantifying the financial and operational impact. This analysis should reference the organization's Business Impact Analysis (BIA) and consider cascading effects on dependent systems, data integrity, and physical asset damage. The output helps determine appropriate disaster recovery investments and RTO/RPO settings.

The primary concern for in-house application development after a vendor announces End of Life (EOL) is the loss of vendor-supported updates, security patches, and technical assistance, which creates significant security and compliance vulnerabilities. When a vendor goes EOL, the organization must decide whether to: (1) Develop an in-house replacement or fork the application, (2) Migrate to an alternative vendor or open-source solution, or (3) Accept the risk with enhanced compensating controls. The key risks include unpatched security vulnerabilities, incompatibility with updated systems, loss of regulatory compliance, and increased maintenance burden. A risk practitioner should conduct a thorough assessment of the application's criticality, security exposure, and migration complexity before deciding on the appropriate risk response. This falls under CRISC Domain 3 (Risk Response) and Domain 4 (IT Principles - vendor management).

In an IaaS model, data encryption protects against unauthorized vendor access by ensuring that even if the cloud provider's personnel gain access to stored or transmitted data, they cannot read it without the encryption keys. The protection works through: (1) Application-layer encryption where the customer manages encryption keys separately from the provider, ensuring the vendor has no access to plaintext data, (2) Data-at-rest encryption using customer-managed keys in a separate key management service, and (3) Data-in-transit encryption using TLS/SSL protocols. The critical factor is that the customer retains sole control of encryption keys — if the vendor also has access to keys, the protection is ineffective. Application-layer encryption is preferred over database-layer encryption because it protects data even if the database server itself is compromised. This aligns with the shared responsibility model where the customer is responsible for data protection in IaaS.

The most important consideration for selecting KPIs in control monitoring is that they must be directly aligned with the specific control objectives and the underlying risks they are designed to mitigate. KPIs should be: (1) Relevant — directly measuring whether the control is achieving its intended purpose, (2) Measurable — quantifiable with clear data sources and calculation methods, (3) Timely — providing information frequently enough to detect control failures before they result in significant risk events, (4) Actionable — enabling control owners to take corrective action when thresholds are breached, and (5) Balanced — covering both design effectiveness and operating effectiveness. ISACA emphasizes that KPIs should be forward-looking indicators of control performance rather than backward-looking metrics that only report past incidents. The KPIs must also be reviewed and updated regularly as risks and controls evolve.

A risk appetite review directly affects the risk register by recalibrating the organization's threshold for acceptable risk levels, which can change the prioritization and treatment of existing risks. When leadership reviews and updates the risk appetite statement, it may: (1) Lower the acceptable risk threshold for certain risk categories, causing previously acceptable risks to be reclassified as high-priority items requiring immediate action, (2) Raise the threshold for other categories, allowing some risks to be accepted without additional mitigation, (3) Trigger the creation of new risk scenarios that were previously outside the organization's risk tolerance, and (4) Update the risk scoring criteria and heat map thresholds used in the register. The updated risk register then drives changes to risk response plans, resource allocation for mitigation, and reporting to the board and audit committee. This is a core CRISC Domain 1 (Governance) and Domain 3 (Risk Response) concept.

The risk response process in CRISC is triggered by several events: (1) Completion of a risk assessment that identifies new risks or updates to existing risks, (2) Changes in the internal or external risk environment (e.g., new regulations, emerging threats, organizational restructuring), (3) Results from control monitoring and testing that reveal control gaps or failures, (4) Occurrence of a risk event or near-miss incident, (5) Scheduled periodic risk reviews (e.g., quarterly or annual), and (6) Changes to business objectives, strategies, or IT systems that alter the risk landscape. The trigger initiates the evaluation of risk response options (mitigate, accept, transfer, avoid) and the development of a risk action plan. ISACA emphasizes that risk response should be a continuous, ongoing process rather than a periodic exercise, with triggers ensuring timely responses to evolving risk conditions.

The greatest concern for application log integrity is unauthorized modification or deletion of log entries, which could conceal malicious activity, obscure the root cause of security incidents, and compromise audit trails. Key integrity threats include: (1) Insider threats from privileged users who can alter logs to hide their actions, (2) External attackers who gain access to logging systems to destroy evidence, (3) System failures or corruption that inadvertently damage log data, and (4) Log flooding attacks that overwhelm logging infrastructure. To protect log integrity, organizations should implement: write-once or append-only storage, cryptographic hashing of log entries, centralized log management with access controls, regular log integrity verification, and separation of duties between log administrators and system administrators. These controls ensure that logs remain tamper-evident and admissible as audit evidence.

Yes, cutoff testing provides indirect (circumstantial) audit evidence rather than direct evidence. Cutoff testing verifies that transactions are recorded in the correct accounting period by examining transactions around a specific date (typically year-end). It provides indirect evidence because it does not directly prove the accuracy or completeness of individual transactions — instead, it allows the auditor to infer whether the overall cutoff controls are operating effectively. If cutoff testing shows that transactions are properly recorded in the correct periods, the auditor can draw reasonable conclusions about the reliability of the period-end financial reporting. Direct evidence would come from methods like confirmation, inspection of original documents, or re-performance. Cutoff testing is a standard audit procedure used in conjunction with other substantive tests to form an overall audit opinion.

Understaffing most directly affects the likelihood (or probability) rating of risks, particularly for risks related to operational failures, human error, and control effectiveness. When an organization is understaffed, existing personnel are stretched thinner, leading to: (1) Increased probability of human error and oversight, (2) Reduced ability to perform control activities adequately and timely, (3) Delayed response to emerging threats and incidents, (4) Lower quality of risk assessments and monitoring activities, and (5) Increased risk of burnout and turnover, creating a vicious cycle. In CRISC risk scoring (Risk = Likelihood x Impact), understaffing primarily elevates the likelihood component because it makes adverse events more probable to occur. However, it can also indirectly increase impact by reducing the organization's capacity to respond effectively when incidents do occur. Risk practitioners should factor staffing levels into their risk assessments as a significant risk multiplier.