CPA ISC Access Controls: Preventive, Detective and Corrective (2027 Prep)

Classify an access control by the job it performs: a preventive control aims to stop inappropriate access, a detective control identifies a problem, and a corrective action addresses a problem already found. A control name cannot prove effectiveness. Approval, review and removal can belong to the same access process while requiring different evidence.

Our fictional museum employee, Sora, moves from invoice viewing to catalog work. The original access-control matrix (CSV) follows that change through proposed controls, and the fictional permission comparison (CSV) supplies an original permission set for a narrated comparison. Nothing has been run on a real system.

Start with the access that the role actually needs

On May 4 in our fictional timeline, Sora's approved invoice-assistant role requires invoice viewing. It permits no invoice editing or catalog access. On May 18, Sora becomes a catalog assistant whose approved tasks require viewing and editing the catalog, with invoice access no longer needed.

The new role needs two permissions. Adding them without removing the old invoice-view permission would leave three, including one outside the new role's supplied requirements. Equal permission counts would not settle the comparison either: two wrong permissions could still fail to match two approved ones. The individual actions matter.

The NIST account-management and audit-record guidance addresses account creation, modification and removal, with access tied to authorization and intended use. It also describes least privilege and reviewing the need for assigned privileges. That publication concerns protecting controlled unclassified information in nonfederal systems, so we use these concepts as technical background without claiming its requirements apply to every museum or define the CPA blueprint.

Explain what prevention is supposed to stop

The University of Florida guidance on control types describes preventive controls as reducing the chance of errors or fraud before they occur, including pre-approval and access controls. For Sora's initial grant, our proposed workflow requires an authorized role request and restricts the granted actions to that role. Invoice editing stays excluded.

A request approved on paper would not by itself show that the system enforced the restriction. The matrix therefore asks for the authorization, configured permissions and evidence of enforcement, with actual results left blank. During the role move, the proposed preventive step replaces invoice access with the approved catalog permissions before Sora uses the new role.

The move is a replacement. Treating it as an addition leaves the old access in place, even if the new permissions were correctly authorized and successfully granted.

Use detection to find the mismatch

For the next part of the example, we supply an invented May 19 permission snapshot containing invoice viewing, catalog viewing and catalog editing. Invoice editing is absent. Comparing that snapshot with the new role identifies invoice viewing as the one excess permission, while both required catalog actions are present.

This is a modeled finding. No live access review occurred. Our proposed detective review compares the current permission set with the current approved role and records the discrepancy for follow-up. It does not remove the permission merely by naming it.

University of Florida's explanation distinguishes finding a problem after it exists from preventing it beforehand, while the F5 Labs explanation of control functions describes detection during or after unwanted activity. Here the unwanted condition is an excess permission already present, so the comparison is detective with respect to that condition. A separate control could block a later attempted use, but that is a different action to explain.

Distinguish a correction request from a completed correction

The proposed response is for an authorized administrator to remove Sora's old invoice-view permission after the mismatch is found. Removal addresses the known excess. F5 describes corrective controls as repairing or restoring resources after unwanted activity, and the function here depends on the condition being addressed rather than the word removal alone.

Creating a removal ticket is insufficient evidence of completion.

Our matrix separates the authorized removal from a fresh permission comparison afterward. The intended corrected set contains only catalog viewing and catalog editing. Actual completion remains blank. A new authorized extraction would need to show invoice viewing absent, with the required catalog actions retained, before the example could support a completed-removal statement.

Checking that result is detective with respect to a failed or incomplete correction. The same access lifecycle can therefore contain a corrective action and a separate detective check, without either label establishing that the controls operated effectively.

Keep evidence linked to the particular action

The blank control-evidence record (CSV) separates the objective, proposed action, expected evidence and actual observation. No effectiveness score is assigned. An approval record can support authorization, a permission extract can show a supplied state, and a documented comparison can identify a mismatch, but each has to be connected to the relevant person, system and time.

NIST's guidance separately addresses generating audit records and reviewing and analyzing them. Having a log does not establish that someone reviewed it or resolved what it showed. In our matrix, review evidence and removal evidence therefore occupy separate fields, while actual observations and dates stay empty because this is an original teaching model.

There is also a departure step. Disabling access according to the organization's authorized departure process is preventive with respect to subsequent unauthorized use, whereas removing a known stale permission after discovery is corrective with respect to that existing condition. Neither classification supplies a universal deadline, complete application inventory or proof that every session and access path has been handled.

Explain the control and the remaining evidence together

Sora's supplied May 19 snapshot has three permissions against two required for the new role, with invoice viewing as the one excess action. The detective comparison identifies it. The proposed authorized removal would correct that condition, and the separate follow-up comparison would check whether the correction actually completed.

Actual results remain unknown. This tutorial supplies no official or recalled question, implemented museum system, audit conclusion or claim that three control labels form a sufficient security program. Its contribution is the traceable role-to-permission comparison and the distinction between proposed correction and verified completion.

The official exam-content page lists separate effective preparation editions, but detailed ISC task alignment remains unverified. Use current authorized instruction for your intended attempt and explain the control's objective, action and supporting evidence together.

2027 preparation edition. Public informational HTML checked October 12, 2026. Sora, the museum, dates, roles and permission snapshot are original fictional teaching material. Permission comparisons are modeled, no live control operation or removal verified. NIST publication scope is nonfederal systems handling controlled unclassified information, not a claim of universal museum requirements or detailed ISC task coverage. No linked PDF, worksheet or assessment inspected. Matching ISC hub, detailed task alignment and fresh source/CMS/live checks required before publication.