Teams often confuse visibility with control. Activity Tracking can show that a user logged in, logged out, or changed a record, but it does not reveal what data changed. That makes it useful for basic monitoring, but weak as a mitigation control. For meaningful assurance, organisations need field-level or SQL-level audit evidence that shows the actual before-and-after values.
Why Activity Tracking Feels Stronger Than It Is
Activity Tracking is often mistaken for evidence of control because it produces visible event history. In practice, it only proves that something happened in an application or system, not whether the action was appropriate, complete, or prevented in the first place. That distinction matters in SoD because the control objective is not just traceability, it is stopping conflicted activity or making it independently reviewable.
The useful way to think about it is as identity and access governance supporting evidence, not as a substitute for a segregation rule. It can help teams confirm that an action occurred, but it does not by itself prove that the actor should have had the ability to perform it, or that two conflicting duties were actually separated.
That is why teams that rely on Activity Tracking alone often overstate control strength. A log entry can show a login, logout, or record update, yet still leave unanswered whether the user had incompatible access, whether a compensating approval existed, or whether the record changed in a way that violated policy.
What Activity Tracking Does, and Does Not, Prove
For SoD purposes, Activity Tracking is strongest as a monitoring layer. It helps auditors and security teams reconstruct who touched a system, when they did it, and which transaction occurred. That is valuable for investigation and deterrence, but it is not the same as proving the control objective of separation.
The missing piece is content-level evidence. If the control question is whether one person created, approved, and posted the same transaction, the answer depends on the actual before-and-after values, the approval path, or the SQL update trail. A generic activity event may confirm that a record changed, but it usually cannot show whether the changed field was the critical one that created the SoD breach.
Segregation of Duties guidance is useful here because SoD is about conflicting power, not just observable motion. If the audit trail cannot distinguish harmless activity from a toxic combination, then it supports detection and review, but not strong mitigation assurance.
What Stronger Assurance Looks Like in Practice
Meaningful assurance comes from evidence that exposes the actual data state, not just the user event. Field-level audit logging, database audit trails, and SQL-level evidence are stronger because they can show the exact values before and after a change, the object modified, and the transaction that caused it. That makes it possible to test whether the activity itself breached a SoD rule.
In a mature control design, Activity Tracking is one layer in a chain. It can trigger review, point investigators to the right transaction, and support exception handling, but it should be paired with controls that validate the underlying entitlement model, role design, and approval path. Without that, teams can end up with excellent visibility and weak prevention.
Where systems support it, teams should also align the evidence source to the risk. Low-risk activity may only need user-level history, while high-risk financial or admin actions need transaction-level proof, database logs, or immutable audit records that can stand up to challenge in an internal control review.
Risk and Threat Considerations
When Activity Tracking is treated as the SoD control itself, the main risk is false assurance. A user can still hold conflicting access, perform an improper transaction, or manipulate the underlying record while the logs only show that some routine action occurred. That creates a blind spot in fraud detection and post-incident reconstruction.
Failure mechanism: The control records events at the activity layer, but not the substantive field changes or approval state needed to test the segregation rule. As a result, the organisation may miss toxic combinations, unauthorized state changes, or deliberate abuse of a single workflow.
Impact: SoD testing becomes incomplete, exceptions are harder to prove, and investigators may be unable to tell whether the control actually prevented a conflict or merely documented it after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Activity Tracking is an audit-event logging issue for monitoring user actions. |
| AU-3 — Content of Audit Records | SoD assurance depends on logging enough detail to show what changed, not just that an event occurred. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Activity Tracking only supports SoD when teams actually review and analyze the records for conflicts. | |
| Recommendation — Define required audit events and retain them for review of sensitive SoD transactions. Capture the object, fields, and outcome so reviewers can verify the substantive change. Review audit records for conflicting actions and escalate anomalies for investigation. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging is central to using Activity Tracking as evidence for SoD monitoring and review. |
| A.8.16 — Monitoring activities | Monitoring turns activity events into operational oversight, but does not by itself prove SoD prevention. | |
| Recommendation — Implement logging that records sensitive actions at a level suitable for SoD review. Monitor privileged and sensitive activities for indications of segregation conflicts. | ||
Practitioner Guidance
What to verify: Treat Activity Tracking as sufficient only for monitoring questions. For SoD assurance, verify that the evidence source captures before-and-after values, the affected fields, and the approval or posting context for the sensitive transaction.
Common mistake: Teams often accept a system event log as proof that a SoD control exists, then discover during audit that the log cannot distinguish a routine update from a conflicted one.
What good looks like: The control set should let reviewers see who acted, what changed, and whether the change crossed a segregation boundary, without having to infer the answer from indirect activity clues.
Practitioner takeaway: If the evidence does not show the actual data change, it is monitoring, not SoD assurance; use Activity Tracking for visibility, but reserve control credit for logs that prove the prohibited state did not occur.
Related resources from NHI Mgmt Group
- What do teams get wrong about segregation of duties in ERP?
- What do teams get wrong about segregation of duties in workforce IAM?
- What do teams get wrong about segregation of duties controls in auditing?
- What do teams get wrong about detecting malicious activity in SaaS and source control environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
