What evidence shows identity security controls are working?
Identity security controls are working when documented, repeatable evidence shows that access is granted appropriately, strong authentication is being used, privileged activity is controlled and exceptions are addressed. Useful evidence includes access review records, MFA reports, authentication and audit logs, privileged-access activity, incident findings and metrics showing whether control failures are detected and corrected.
Evidence shows identity security controls are working when it demonstrates that they operate as designed, cover the right identities and systems, and produce appropriate results over time. A policy, configuration screen or completed checklist may show that a control exists; effective assurance requires records that prove it has been applied consistently, tested against defined criteria and improved when weaknesses are found.
Start with a defined control objective. Each control should state what it is intended to prevent or detect. For example, an objective might be that access is removed when a person leaves the organisation, that elevated permissions are limited to an approved business need, or that unusual sign-in activity is investigated. Evidence can then be assessed against a specific question: did the control achieve its intended result, for the relevant population and during the period being reviewed?
The strength of the evidence depends on more than its existence. A useful record should identify the user, account, application or system concerned; show when the activity occurred; identify the person or process responsible; and preserve enough detail to reconstruct what happened. Records should be protected from unauthorised alteration, retained for a defined period and linked to the relevant ticket, approval or investigation where appropriate.
Look for complete and accurate coverage. A review of ten accounts cannot demonstrate that an organisation’s entire identity estate is controlled unless the sample has been selected using a documented method and the limitations are understood. Assurance should consider employees, contractors, administrators, dormant accounts, machine identities and accounts used by external parties where they can access business systems. Reconciliation between identity directories, HR records, application inventories and privileged-access records can reveal accounts that have been missed.
Evidence should also show that controls operate at the points where risk changes. Important examples include a new starter receiving access, a role changing, an account being disabled, a privileged permission being granted, an authentication method being reset, or an application being connected to the organisation’s identity service. Testing these events helps establish whether the control works in practice rather than only in its normal, steady state.
Assess exceptions rather than hiding them. A control can still be effective when exceptions exist, provided they are identified, justified, approved by an appropriate owner, given an expiry date and reviewed until closed. An unexplained exception, a repeated temporary approval or an account that remains enabled after its business need has ended indicates that the control is not operating as intended. Exception trends are often more informative than a single successful review because they show whether weaknesses are isolated or systemic.
Useful testing methods include:
- Inspecting a sample of access changes from request through approval, implementation and subsequent verification.
- Reperforming a control, such as checking whether leavers’ accounts were disabled in line with the organisation’s stated process.
- Comparing records from separate sources to identify discrepancies in users, roles or account status.
- Reviewing a selection of privileged activities to confirm that the action, authorisation and business purpose can be explained.
- Testing detection and escalation by using controlled scenarios or examining previously handled events.
- Checking that identified weaknesses resulted in documented corrective action and later validation.
Measure control performance over time. A single successful test provides limited assurance. Repeated testing can show whether access decisions are becoming more accurate, whether overdue reviews are declining, whether inappropriate permissions are being removed and whether investigations are completed within the organisation’s own defined targets. Metrics need clear definitions: a high completion rate for reviews, for example, does not prove that reviewers examined access carefully or that unsuitable permissions were removed.
Trend information should be separated from raw activity volume. More alerts may mean that detection has improved, or that the environment is generating excessive noise. Fewer incidents may indicate reduced risk, but could also result from incomplete logging or weak reporting. Metrics should therefore be interpreted alongside sampling, case quality, system coverage and the outcome of independent testing.
Check that evidence is independently credible. The person who requests or administers access should not be the only person deciding that the control worked. Independence can be achieved through a separate reviewer, a control owner outside the operational team, internal audit or an external assessment, depending on the risk and assurance requirements. The reviewer should have enough technical and business context to challenge approvals, investigate anomalies and record the basis for the conclusion.
A mature evidence pack normally includes the control description, scope, system and identity populations, test method, sample rationale, results, exceptions, responsible owners, corrective actions and follow-up dates. It should distinguish between evidence that a process was performed and evidence that the result was appropriate. This distinction is important: an access review may be completed correctly as an administrative exercise while inappropriate permissions remain in place.
Finally, evidence is strongest when it supports a closed feedback loop. Findings should be prioritised according to risk, assigned to an accountable owner, tracked to completion and retested. If the same failure recurs, the underlying process, role design, system integration or governance decision may need to change. In this way, identity security assurance becomes an ongoing control-testing process rather than a one-off collection of documents.
Evidence of identity security effectiveness must be evaluated for its quality as well as its presence. Reliable evidence is relevant to the control being tested, produced close enough to the event to reflect actual conditions, complete enough for the decision being made and difficult for unauthorised people to alter. A report that merely states “MFA enabled” is less informative than evidence showing which accounts were covered, which authentication methods were used and how failed or bypassed attempts were handled.
Evidence should also be corroborated where the risk justifies it. For example, an identity platform report can be compared with endpoint, application or network records to confirm that authentication activity corresponds with real system use. Differences do not automatically prove a control failure, but they should have an explained cause, such as an excluded system, a synchronisation delay or an approved technical exception.
The conclusion should match the evidence available. If records cover only a particular application, user group or review period, the finding should be limited to that scope rather than presented as assurance over the whole identity environment. Clear boundaries make evidence more useful because decision-makers can see what has been demonstrated, what remains uncertain and where further testing is required.
