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

The classification between key and non-key controls is the single most-revised field in ISAE 3402 reports. You have built the control matrix, documented eleven controls across seven objectives, and the EP 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 International Standard on Assurance Engagements (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 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 Service Organization Controls (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 and the existence (or absence) of compensating controls. 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 review note.

The problem runs deeper than documentation. A vague classification often means the engagement team has not 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. Classifying a control as key is the field that generates the most RNs on the ICFR working paper, yet many teams just SALY the control list from last year and call it done. 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 as a tick box exercise, 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 tick box 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 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 in quantified terms.

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 four downstream decisions that directly affect the engagement: testing intensity, deviation consequences, gap analysis severity, and the final opinion the EP signs.

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. Get the rationale right at the control matrix stage and you prevent a chain of downstream errors. Get it wrong and every WP after it carries the same defect.

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 and why the original classification is no longer appropriate. 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 in a way that would never have survived scrutiny at the planning stage. 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.

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

Practical checklist

Common mistakes

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.

Related tools

Put audit concepts into practice with these free tools: