Key vs Non-Key Controls in ISAE 3402: The Classification That Triggers Every Review Comment

You've built the control matrix, documented eleven controls across seven objectives, and the engagement partner sends it back with one comment: "The key/non-key rationale is vague." You thought "KEY because it's important" was enough. It never is.

A key control in an ISAE 3402 engagement is one whose failure alone could prevent achievement of the related control objective, with no compensating detective control providing equivalent coverage. Non-key controls provide supplementary assurance where a primary key control already addresses the risk. The classification drives testing scope, sample sizes, and the opinion when deviations are found.

The distinction matters downstream in ways that are not always obvious at the planning stage.

Why this classification generates more review comments than anything else

The AFM's inspection findings on ISAE 3402 engagements consistently identify vague or missing rationale for the key/non-key classification. The PCAOB has raised similar observations in its inspection of firms performing SOC engagements under the parallel US standard, AT-C 320. The reason is straightforward: a control marked "KEY" without an explanation of why it is key tells the reviewer nothing about whether the engagement team understood the control environment.

The classification is not a label you apply after the fact. It is an analytical conclusion that follows from evaluating the control's role in addressing a specific risk, the existence (or absence) of compensating controls, and the consequences of the control's failure. When the rationale column in the control matrix is empty or contains one-line statements like "key because it addresses a high risk," the reviewer cannot evaluate whether the classification is correct. That gap between label and reasoning is what triggers the comment.

The problem runs deeper than documentation. A vague classification often means the engagement team has not actually analysed the control environment. They have listed controls and labelled them, but they have not thought through which controls are doing the real work and which are supplementary. The classification exercise forces that analysis. When done properly, it produces a control matrix where the relationship between controls is visible: this control is key because nothing else catches this risk, and that control is non-key because this other control already covers it. When done superficially, every control looks the same, and the reviewer has no way to distinguish the controls that matter from the ones that do not.

ISAE 3402 itself does not prescribe a specific methodology for key/non-key classification. The standard refers to controls "that address the risks" (paragraph 23) and requires the service auditor to identify those controls relevant to the control objectives. The key/non-key distinction is a methodological tool developed in practice to differentiate controls that require testing from controls that exist as supplementary layers. Firm methodology manuals formalize it, but the underlying logic is consistent across firms.

The three-question rationale test

Every key/non-key rationale must answer three questions. The ISAE 3402 template pack builds these into the control matrix as mandatory fields, but the logic applies regardless of the template you use.

Question one: what risk does this control address? The answer must reference a specific risk from the risk assessment, not a general category. "Addresses access risk" is insufficient. "Prevents unauthorized users from retaining ERP access after role changes, which could result in unauthorized transactions affecting user entity financial reporting" connects the control to a specific threat with a specific consequence.

Question two: does a compensating control exist? If another control in the matrix independently addresses the same risk with equivalent or near-equivalent coverage, the control under evaluation may be non-key. The word "independently" matters. A detective control that only catches errors in 30% of cases is not a compensating control. A quarterly review that catches all unauthorized access changes within three months is a compensating control for the purpose of evaluating whether a real-time preventive control is the sole key control.

Question three: what happens if this control fails? If the control fails and no compensating control catches the failure before it affects the control objective, the control is key. If the control fails but a compensating control catches the exposure within an acceptable timeframe, the control may be non-key. The answer here must be specific about the exposure window and the consequence for user entities. "The control objective would not be achieved" is a conclusion, not an analysis. State what goes wrong: unauthorised users retain access for up to three months, or payroll errors propagate to all user entities before the next reconciliation cycle. The specificity of the failure analysis is what distinguishes a defensible rationale from a box-ticking exercise.

The exposure window deserves particular attention. A control that fails but is compensated within 24 hours by an automated alert creates minimal exposure. A control that fails with no compensating detection for six months creates substantial exposure. The window determines whether the compensating control is genuinely effective as a substitute, or whether it is merely a secondary check that catches problems too late to prevent the damage.

A control is key when the answers reveal: the risk is specific and material, no compensating control provides equivalent independent coverage, failure leads directly to a gap in reasonable assurance over the control objective, and the exposure window before detection is unacceptable.

A control is non-key when: a compensating control exists that independently addresses the same risk, or the control provides a supplementary layer of assurance above what is already covered by a key control. Non-key does not mean unimportant. It means the control is not the primary mechanism preventing or detecting the risk.

The rationale must be written, not just thought through. A classification that seems obvious to the engagement team is not obvious to the reviewer. The reviewer reads the rationale column without the context of the planning discussions, the walkthroughs, or the team's understanding of the control environment. If the rationale column is blank, the classification is unsupported regardless of how sound the underlying reasoning was. This is the point the AFM and PCAOB inspectors make repeatedly: the classification may be correct, but without a written rationale, they cannot evaluate it.

Key controls: what the classification means in practice

Consider a logical access review performed quarterly by the Information Security Manager. The ISM obtains the full user access listing from the ERP system, compares it against the approved access matrix, investigates discrepancies, removes unauthorized access, and documents the resolution for each finding. This control addresses the risk that former employees or employees who changed roles retain inappropriate access to financial processing functions.

Is there a compensating control? If no other control independently detects unauthorized access between quarterly reviews, this control is key. A daily automated log of failed login attempts does not compensate because it only catches failed access, not successful unauthorized access. An annual certification by the application owner provides a thorough but far less frequent check. The quarterly review is the primary mechanism.

What happens if it fails? Unauthorized users could retain ERP access for up to a full year (until the annual certification catches it, if it does). Transactions processed under unauthorized access could affect user entity financial statements. The control objective for logical access cannot be achieved if the quarterly review is not performed.

The rationale for this control reads: "Primary preventive control over ERP access. No compensating detective control provides equivalent coverage between quarterly cycles. Failure alone prevents achieving the logical access control objective. Classified KEY."

That is a rationale a reviewer can evaluate. It identifies the role and the absence of compensation, then states the failure consequence.

Non-key controls: not unimportant, just not primary

Take a backup integrity check performed daily by an automated system. The backup monitoring system executes daily incremental backups and runs integrity checks against checksums. If a check fails, the system generates an alert. This control supports data availability.

But data availability is also addressed by change management controls (which prevent unauthorized modifications to production data) and by the recovery procedures tested during disaster recovery exercises. The backup is a recovery mechanism. It compensates for data loss events rather than preventing them. If the backup integrity check fails for a single day, the change management controls still prevent unauthorized data changes, and the previous day's backup remains available.

The rationale: "Detective control over data availability. Classified non-key because change management provides primary protection over data integrity. Backup is a compensating recovery mechanism, not the primary control. Failure is detectable through daily monitoring alerts, and exposure is limited to one day's incremental data."

That rationale explains the classification by reference to the primary control and the compensating relationship, then quantifies the limited exposure window.

How classification flows into testing and the opinion

The key/non-key classification is not an academic exercise. It drives three downstream decisions that directly affect the engagement.

Testing intensity. Key controls require testing for operating effectiveness in a Type II engagement. Standard sample sizes for key controls follow ISA 530 by analogy: quarterly controls tested at 100%, monthly controls tested at 3 to 5 samples (higher for high-risk classifications), weekly controls at 5 to 9, daily controls at 25. Non-key controls may be tested at lower sample sizes or, depending on firm methodology, tested only for design effectiveness. The ISAE 3402 template pack includes a sample size reference table calibrated to control frequency and risk classification.

Deviation consequences. When a key control has a deviation that breaches the tolerable deviation rate, the engagement team must assess whether the control objective can still be achieved. If no compensating control covers the exposure, the path leads to a qualified or adverse opinion under ISAE 3402 paragraph 53. When a non-key control has a deviation, the consequences are typically limited to reporting the exception. The control objective may still be achieved through the primary key control.

Gap analysis severity. In the gap analysis, a deviation in a key control with no compensating coverage is rated HIGH severity. A deviation in a non-key control where the related key control operated effectively is rated LOW. The entire severity assessment framework depends on the key/non-key classification being correct. If a control was incorrectly classified as non-key and its related "key" control also failed, the aggregation assessment understates the overall deficiency.

This is why reviewers focus on the classification. An error here cascades through testing and evaluation into the opinion. Getting the rationale right at the control matrix stage prevents a chain of downstream errors.

Reclassification during the engagement

The initial key/non-key classification is made during planning, but it may change during the engagement. If testing reveals that a compensating control classified as key actually has a 40% deviation rate, the control it was compensating for may need reclassification from non-key to key. The reverse also applies: if a control was classified as key because no compensating control was identified at planning, but fieldwork reveals an additional detective control that was not documented in the control matrix, the classification may be reconsidered.

Any reclassification must be documented with the same three-question rigour as the original classification. State what changed, why the original classification is no longer appropriate, and what the revised rationale is. The testing already performed must be evaluated against the revised classification. If a control reclassified from non-key to key was tested with a lower sample size, additional testing may be required.

Reclassification late in the engagement is a risk indicator. If the engagement team is reclassifying controls at the reporting stage to avoid a qualified opinion, the reviewer will question whether the reclassification is justified or whether it is being used to manage the outcome. Document the timing and the trigger for any reclassification.

Worked example: Brouwer IT Services B.V.

Scenario: Brouwer IT Services B.V., a managed hosting provider based in Rotterdam, serves 28 user entities with combined annual revenue of €85M processed through its infrastructure. The engagement team is building the control matrix for a Type II engagement covering 1 January to 31 December 2025. Two controls address the same control objective (logical access to the hosting management console): a quarterly access review and an annual access certification.

1. Identify the two controls and the risk they address. The quarterly access review (performed by the Security Operations Lead) compares active console accounts against the approved access list. The annual access certification (performed by the Service Delivery Director) recertifies all accounts against job roles. Both address the risk that unauthorised personnel retain console access, enabling configuration changes that affect all 28 user entities. Documentation note: Record both controls in the control matrix with the same risk reference. Note that both address the same control objective for logical access.

2. Apply question one to each control. Both controls address the same risk: unauthorised console access leading to potential configuration changes that affect user entity data integrity. The risk is rated HIGH because the hosting console controls infrastructure serving all user entities. Documentation note: Record the risk description and rating in the rationale column for both controls.

3. Apply question two: compensating controls. For the quarterly review, ask whether the annual certification provides compensation. The annual certification is less frequent (once per year versus four times). Between quarterly reviews, the maximum exposure window is three months. Between annual certifications, it is twelve months. The quarterly review provides more timely detection. For the annual certification, the quarterly review provides more frequent coverage of the same risk. Documentation note: In the quarterly review rationale, state that no control provides more frequent or equivalent coverage. In the annual certification rationale, identify the quarterly review as the primary control providing more frequent coverage.

4. Apply question three: failure consequences. If the quarterly review fails and no other control operates, unauthorised access could persist for up to twelve months (until the annual certification). That is an unacceptable exposure window for a HIGH-risk control objective. If the annual certification fails but the quarterly review continues to operate, unauthorised access is caught within three months. The exposure is limited. Documentation note: Record the failure analysis for each control. State the exposure window in months.

5. Classify and document. The quarterly access review is classified KEY: primary detective control, no compensating control provides equivalent frequency, failure alone prevents achieving the control objective. The annual certification is classified NON-KEY: supplementary detective control, the quarterly review provides more frequent equivalent coverage, failure alone does not prevent achievement because the quarterly review catches the same exposures within three months. Documentation note: Record the full rationale in the control matrix rationale column, answering all three questions for each control.

A reviewer sees two controls addressing the same risk, with the classification explained by reference to frequency, coverage and exposure windows, with the compensating relationship between them clearly documented.

Practical checklist

1. For every control in the matrix, complete the rationale column before submitting for review. Answer all three questions: risk addressed, compensating control existence, failure consequence.
2. Check that every key control has an explicit statement of why no compensating control provides equivalent coverage. "No compensating control exists" alone is incomplete; state what coverage is missing.
3. Check that every non-key control identifies the related key control by name and explains how that key control provides primary coverage of the same risk.
4. Verify that the classification is consistent with the testing approach. A control classified as key but tested with a sample size appropriate for non-key controls will be flagged.
5. Review the gap analysis to confirm that severity ratings align with the key/non-key classifications. A high-severity finding on a non-key control (or a low-severity finding on a key control with no compensating coverage) signals a classification error.

Common mistakes

• Classifying all controls as key to avoid the analysis. This inflates testing scope without improving quality and signals to reviewers that the engagement team did not evaluate the control environment. The AFM has noted that blanket key classifications indicate a lack of understanding of the control structure.
• Writing a one-line rationale that restates the classification ("KEY because it is a key control") without answering the three questions. This is the single most common review comment on ISAE 3402 control matrices across both AFM and PCAOB inspections.
• Classifying a control as non-key without identifying the compensating key control. If no compensating control is named, the non-key classification has no basis, and a reviewer will ask what prevents a gap in assurance if both this control and its unnamed compensator fail.

Related content

• ISAE 3402 glossary entry. Covers the structure of a Type II engagement, control objectives, and the relationship between the service auditor's work and the user auditor's reliance assessment.
• ISAE 3402 template pack. The control matrix includes the key/non-key column with the three-question rationale structure described in this post, plus 11 fully worked example controls showing both KEY and NON-KEY classifications with complete rationales.
• ISAE 3402 gap analysis: from deviation to opinion in four worked examples. Shows how the key/non-key classification drives severity ratings and opinion impact when deviations are found during testing.