What is the difference between certification evidence and simulation output?

How certification evidence differs from simulation output

certification evidence is a record of human or governance action, so its value is auditability: it shows that someone reviewed the change, accepted the decision, and preserved that decision for later inspection. Simulation output is an artefact of analysis, so its value is decision quality: it shows what the proposed change would do before you commit to it.

That difference matters because the two artefacts answer different questions. Certification evidence says, “Was this change formally reviewed?” Simulation output says, “What happens if we make this change?” One supports accountability after the fact, the other supports judgment before implementation.

In practice, teams often treat them as interchangeable because both may sit in the same change record or approval workflow. They are not interchangeable. A strong simulation can still be rejected, and a well-documented certification can still approve a weak proposal. The artefacts are complementary, but they are not proof of the same thing.

Why each artefact exists in a governance workflow

Certification evidence exists to make decisions defensible. It gives auditors, reviewers, and control owners a traceable trail that a proposal was considered, approved, or rejected according to process. It is especially important where the organisation needs to demonstrate segregation of duties, change control discipline, or formal sign-off.

Simulation output exists to reduce uncertainty before action. It is the output of a model, test, dry run, or what-if analysis that helps the team understand likely consequences, side effects, or failure modes. When the proposed change touches access, policy, routing, configuration, or automation, simulation is often the fastest way to expose unintended impact.

For change-heavy environments, the most useful distinction is temporal. Certification evidence is retrospective and procedural. Simulation output is prospective and analytical. If the change is already approved but not yet applied, simulation can still refine the plan; if the change is already applied, certification evidence can still support audit and accountability.

For teams building formal controls, the closest governance parallel is access review discipline, where the decision record matters separately from the analysis that informed it. NHIMG’s IAM and IGA Basics is a useful foundation for that separation between authorization evidence and governance decisions.

How to tell which one you need

Use certification evidence when the question is about proof of process: who approved, what was approved, when it was approved, and under what control. Use simulation output when the question is about predicted behaviour: what will break, what will change, and whether the intended effect is actually what will happen.

If the risk is “can we defend this decision later?”, you need certification evidence. If the risk is “will this decision produce the outcome we expect?”, you need simulation output. In mature change governance, both should be retained together, but they should never be confused in review or reporting.

When simulation output is strong but the approval record is weak, the organisation has a governance gap. When the approval record is strong but the simulation is absent or superficial, the organisation has a validation gap. The better practice is to make both visible in the same change packet, while preserving their separate meaning.

For access and entitlement changes, the same logic applies to review evidence versus impact analysis. NHIMG’s Access Reviews and Certification Guide helps distinguish review artefacts from the operational evidence used to justify them, and IGA Buyer's Guide shows how review workflows, lifecycle controls, and evidence collection fit into a broader governance process.

Risk and Threat Considerations

Confusing certification evidence with simulation output creates two kinds of failure: audit failure and decision failure. Teams may believe a change is safe because it was approved, or believe it is governed because it was simulated, when neither artefact proves the other condition.

Failure mechanism: review records can become rubber stamps, while simulation results can be treated as operational approval. That weakens control separation and can let high-impact changes proceed without real validation or without a defensible approval trail.

Impact: the organisation can lose auditability, miss unintended side effects, and approve changes based on incomplete assurance. In access and governance contexts, that can also leave entitlement decisions, role changes, or policy updates insufficiently justified or insufficiently tested.

Practitioner Guidance

What to verify: keep the approval record and the simulation artefact separate in the change package. The certification should show who made the decision and why; the simulation should show what was evaluated and what effect was predicted.

Decision rule: if the reviewer cannot explain the simulated impact in plain terms, the change is not ready for certification. If the simulation exists but no accountable approver is recorded, the change is not governed even if the technical analysis looks sound.

Practitioner takeaway: treat certification evidence as proof of governance and simulation output as proof of analysis, then require both before you trust a material change.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?