Free Certified in Risk and Information Systems Control (CRISC) practice test: 30 questions with answers

Before deciding on a response, the practitioner needs to know how far the failure reaches, which requires testing the control's design and how it operated over the period. Removing the control, granting a long exception, or replacing it all act before the facts are established.

An effective KRI is a leading signal whose threshold is set against appetite, so a breach prompts action before a loss happens. Lagging figures and post-incident measures describe what already occurred, and a regulator-only indicator gives management nothing to act on.

Risk response options include mitigating the risk by improving controls and transferring part of its impact, such as through insurance, both of which can bring exposure back within appetite. Accepting without an owner, waiting for an audit, or deleting the entry each hide the risk rather than responding to it.

A breach at a provider is handled through the provider's obligations: the practitioner checks the assessment and contract terms, then establishes what data was exposed and what the organization must do. Moving in-house is a strategic decision that may not be warranted, waiting on a renewal is too slow, and deleting your own logs destroys the evidence needed to investigate.

An operating deficiency means a control whose design is adequate is not performing as intended in practice. A design deficiency would mean the control could not meet its objective even if it were performed correctly, while inherent gap and scope exclusion describe other concepts.

Repeated slippage should be escalated to the accountable owner and governance forum, with a realistic revised date and an explanation of the exposure that the delay creates. Leaving it open, resetting it by reopening, or lowering the rating each conceal a control weakness rather than managing it.

Senior management needs a view of the risk profile against appetite, the exposure it represents, and whether actions are progressing. Scan results, full policy text, and raw log counts are operational detail that would obscure the decision the report is meant to support.

The control was designed to remove unneeded access and was carried out, but it did not achieve its purpose, which is an operating deficiency. A design problem would mean the quarterly review could not work even if performed well, and the other options describe risk levels rather than control performance.

Risk ownership assigns accountability and the documented authority to accept residual risk within the approved appetite. Training and scanning are useful controls, but neither establishes who may accept an exception. The roadmap addresses platform lifecycle rather than acceptance authority.

Risk appetite states how much risk the enterprise is prepared to pursue in general, and risk tolerance sets the boundary of acceptable deviation for a particular objective. The second option swaps the two terms, and the other options describe artifacts or formats that are not defined by these terms.

Internal audit is the third line and reports to the audit committee, which gives it the independence needed to assess whether controls work. The first line operates the controls and the second line sets the framework, so both are part of management and cannot provide that independent view.

A policy sets the principle while a standard defines measurable requirements, so the missing algorithms and key lengths belong in the standard. Vendor-specific policies duplicate effort and drift apart, and a higher approval level does not add the detail that is missing.

Approved appetite statements give decision makers a reference point, and named ownership makes the leader who benefits from a business decision also answerable for its risk. Reactive discussions after incidents and sharing test results with one team do not connect risk to decisions, and centralising purchasing is an organizational choice rather than a governance link.

An organization cannot assess, protect, or assign ownership for assets it has not identified, so a register with owners and classifications is the foundation. Data loss prevention and encryption are valuable later, but both assume the organization already knows what it holds and how sensitive it is.

A healthy risk culture shows up in people raising problems early, including near misses, without being punished for them. A clean audit record or a rising register count can each reflect reporting gaps or changing scope rather than good behaviour, and a fixed review cycle measures the calendar rather than the culture.

Separate reporting lines keep the people who check risk from being managed by the people whose decisions they check. The other options describe speed, cost, or power, none of which is the reason for the structure, and the last one describes an abuse of the role rather than a principle.

A risk scenario needs a threat event acting on a specific asset through a specific weakness, because the likelihood and impact estimates depend on those three elements. Budget, insurance vendors, and audit dates may matter later for response decisions, but they do not define the risk itself.

The recovery time objective is the maximum tolerable time to restore a service, so a test that takes longer than that limit is a shortfall against it. A recovery point objective concerns how much data may be lost, which the scenario does not mention, while inherent risk and design deficiency describe different concepts.

Inherent risk is the exposure estimated without the effect of existing controls, and it is the baseline against which control effectiveness is judged. Residual risk is what remains after controls, while acceptance and transfer are responses that come after the assessment.

Compensating controls can lower the practical risk of a vulnerability, but the finding still needs a documented assessment and a decision by the owner. Closing it without review or excluding the server from scanning removes the evidence, and escalating every critical finding to the board ignores the context that makes this one lower risk.

External threat intelligence and industry reports show threats that other organizations have seen, which is how new risks are identified before they reach your own logs. Internal logs and audit findings only reveal what has already happened to you, and contract review is useful for vendor risk rather than threat identification.

Expressing loss exposure in money lets the organization compare the annualized loss a control would prevent with what the control costs. Quantitative estimates still carry uncertainty, and they still rely on owner input and a register, so the other options overstate what the method does.

A register entry needs an accountable owner with a review date, and the ratings that show the risk before and after controls. Individual performance data, marketing material, and closed-risk history do not describe the risk itself and are not needed to manage it.

Classification, encryption, and secure disposal address different lifecycle stages, from creation through to end of life. Indefinite retention and broad read access both increase exposure, and they conflict with the data minimisation that a lifecycle approach expects.

A cloud move shifts some security responsibilities to the provider, so the boundary and the exit terms determine what risk the organization keeps. Dashboard colours, office location, and device count are operational details that do not change the risk position in a meaningful way.

A change process with approval, peer review, and recorded evidence prevents unauthorized changes and allows rollback when a change fails. Meetings and password length have little effect on who may change configuration, and an editable shared folder increases the risk it is meant to reduce.

Security requirements and tests at each phase catch design and build flaws when they are cheapest to fix. Testing only at acceptance, ignoring non-production environments, and skipping documentation all push risk later into the lifecycle where it costs more to correct.

Recovery procedures are only credible when they are tested against the objectives set by the impact analysis. A backup in the same facility, untested plans, and knowledge held by one person each fail when a single site or person is unavailable.

Customer conversations may contain personal data that the vendor could retain or use, so data exposure is the primary risk to assess before deployment. Typeface, price, and training numbers matter for adoption and cost, but they do not describe the most serious harm.

Peer review before merging catches defects before they enter the main line, and it is one of the cheapest controls in the development process. Deploying from workstations, granting broad production rights, and skipping test environments all remove checks that would otherwise catch defects.