Skip to content
Sentinel Unity

For Internal Audit

Evidence you can follow back to its source

Every finding keeps its origin, every control keeps its mapping reasoning, and platform activity is written to an append-only log, so testing does not begin with reconstructing what happened.

  • Immutable platform audit log, alongside per-module trails
  • Segregation-of-duties conflict rules with recorded exceptions
  • Evidence passed through explicit review, not just attached
  • Permission bundles granular enough to evidence who could do what
Asset module permission bundles by lifecycle action
Actionasset-viewerasset-coordinatorasset-approverasset-admin
ViewAllowedAllowedAllowedAllowed
Create and editNot allowedAllowedNot allowedAllowed
Submit for intakeNot allowedAllowedNot allowedAllowed
Send to reviewNot allowedAllowedNot allowedAllowed
Send backNot allowedAllowedAllowedAllowed
ApproveNot allowedNot allowedAllowedAllowed
ActivateNot allowedNot allowedAllowedAllowed
Module settingsNot allowedNot allowedNot allowedAllowed

Every module ships bundles at this granularity. Segregation-of-duties conflicts are declared as rules, with logged exceptions.

Goals & pressures

What you are accountable for

Sentinel Unity is shaped around how this role actually works in regulated organizations, not generic GRC marketing language.

Goals

  • Establish who could perform an action, not just who did
  • Trace a reported score back to the evidence behind it
  • See remediation sequencing and where it actually stalled
  • Test control design and operation as separate questions

Common pressures

  • Audit trails that can be edited by an administrator
  • Role models too coarse to demonstrate duty separation
  • Evidence folders with no record of who accepted them
  • Findings whose originating assessment is no longer identifiable

See Sentinel Unity from the internal audit seat

A walkthrough scoped to the work you actually own, using your frameworks and entity structure.