What control evidence do auditors and regulators need when SCA fails?

What auditors are actually looking for when SCA fails

When strong customer authentication is expected but cannot be completed normally, the control question shifts from “did the transaction happen?” to “can you prove the correct authentication path was used and tied to this specific action?” Auditors and regulators need evidence that shows the authentication method, the transaction binding, and the retention of that evidence in a form that cannot be quietly altered after the fact.

The evidence has to support reconstruction, not just reporting. A log entry that says a payment was approved is weaker than records that show the authenticating party, the method used, the transaction details that were authorised, and the exact event trail retained for review. That is why transaction logs alone are often insufficient when they do not show the authentication context behind the authorisation.

For financial services teams, the control expectation is usually strongest where the process depends on dynamic linking, step-up authentication, or other regulated proof that the approval was bound to the value and payee or recipient. NHIMG’s Financial Services Identity Security Guide covers the identity and access control obligations that sit around SCA, dynamic linking, and regulated payment flows.

What good evidence looks like in practice

Good evidence is specific enough to answer three questions without guesswork: who authenticated, how they authenticated, and what transaction or instruction that authentication authorised. In practice that usually means immutable or tamper-evident records, precise timestamps, a clear correlation identifier across the authentication and transaction systems, and a retention trail that can be reproduced for audit review.

Auditors also look for consistency between policy and implementation. If your control says a transaction must be bound to an authentication event, the evidence should show that the binding is deterministic, not inferred later from separate records. If the evidentiary trail depends on manual reconciliation, screenshots, or ad hoc exports, the control will look weaker even if the transaction itself was legitimate.

Retention matters as much as capture. Records should be protected so that administrators, developers, or support teams cannot rewrite the story after the event, whether intentionally or accidentally. In regulated environments, the durability of the audit trail is part of the control, not just a storage detail.

How to close the gap when the primary record is incomplete

When SCA evidence is incomplete, the fix is usually to strengthen the control design rather than to assemble a better narrative after the fact. The most common gap is that authentication and transaction systems are separated in a way that makes it hard to prove linkage later. The better pattern is to generate a durable control record at the moment of approval, with the authentication result, transaction attributes, and signing or authorisation event bound together.

That evidence model should be checked against the actual failure mode. If the control sometimes falls back to an alternative method, the audit trail must still show why the alternative was permitted and whether it met the required assurance level. If a transaction was authorised through a compensating workflow, the evidence should make the exception obvious rather than burying it in generic operational logs.

For standards-based control design, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the right control family references for identification, authentication, auditability, and record integrity, while NIST SP 800-63 Digital Identity Guidelines helps frame authenticator strength and proofing expectations. Where the issue is cryptographic protection of the evidence trail itself, NIST SP 800-57 Key Management is the relevant reference for keeping signing and verification material under control.

Risk and Threat Considerations

If SCA evidence is weak, the risk is not only audit finding exposure. It can also create a hidden control failure where unauthorised or weakly authenticated transactions are treated as compliant because the log trail is incomplete, ambiguous, or editable after the event.

Failure mechanism: The organisation records transaction activity, but not the full authentication context or cryptographically trustworthy linkage between the authentication step and the authorisation step. That leaves room for disputed approvals, missing accountability, and tampering with the evidentiary trail.

Impact: Investigations become slower and less conclusive, regulatory confidence drops, and the organisation may be unable to prove that a control operated as intended when it mattered most.

Practitioner Guidance

What to verify: Confirm that your evidence chain can answer the audit question in one pass: authenticated identity or actor, authentication method, transaction binding, and immutable retention. If any one of those four elements is missing, the control is not yet audit-ready even if the transaction log is clean.

Common mistake: Teams often assume system logs are enough because they show activity, but a log that cannot prove the authentication path or the binding to the authorised transaction will usually fail under scrutiny. Treat “traceable” and “provable” as different thresholds.

Practitioner takeaway: The control test is evidentiary, not procedural: auditors need a record that proves the right authentication happened, that it authorised the right transaction, and that the proof itself could not be quietly rewritten later.

Related resources from NHI Mgmt Group

• How should financial institutions implement access reviews that auditors will accept as evidence of control?
• Who is accountable when human risk controls are not producing evidence for auditors and regulators?
• How should compliance teams improve audit readiness as regulators demand more precise control evidence?
• Who is accountable when control monitoring fails to produce audit-ready evidence?