Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to audit sensitive data access across enterprise applications?

Cross-application auditing works when access events share a common shape, who acted, what was accessed, when, from where and with what result, and when the work is recorded at the layer where it happens for systems whose logs fall short. Without both, the trail is fullest where risk is ordinary and thinnest where sensitive data is handled by exception.

Records from database, cloud and application windows converge at a shared audit gate.

Cross-application auditing works when access events share a common shape, who acted, what was accessed, when, from where and with what result, and when the work is recorded at the layer where it happens for systems whose logs fall short. Without both, the trail is fullest where risk is ordinary and thinnest where sensitive data is handled by exception. The enterprise problem is rarely a shortage of logs. Each application keeps its own, in its own format, under its own retention, and several important systems, including third party portals and older internal tools, keep records that are hard to reach at all. Auditing across that estate has two parts: normalize what exists, following the audit content and review expectations in NIST SP 800-53, and cover the territory where per application logging fails by recording the work where it is performed. Microsoft's unified audit log is the clearest example of normalization within one vendor's estate. An AI Control Record that captures an agent's activity across applications in a single record shows what the second part looks like. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • NIST SP 800-53 expects audit records to carry enough content to establish what occurred, and expects those records to be reviewed, analyzed, and reported as a routine control activity, across the systems in scope (NIST, 2020).
  • Microsoft's unified audit log shows normalization working inside one estate: user and administrator activities from many Microsoft 365 workloads are stored in a single searchable record with common fields such as user, activity, time, workload, and source (Microsoft, 2025).
  • The unified model's boundary is the vendor's own estate. Applications outside it, including the portals and legacy systems where sensitive work concentrates, do not write into it, so cross application audit assembled only from platform logs has structural holes (Microsoft, 2025).
  • AI agent activity creates a new audit subject: the relevant events are what the agent was shown, what it did, and who approved its consequential steps, and those events span every application the workflow touches (What Is a Governed AI Workflow?).
  • Recording the work at the layer where it happens, as RedactSure describes for its AI Control Record, produces a cross application trail for governed workflows that does not depend on each application's own logging maturity.

What makes cross application auditing hard in practice?

Start with format. One application logs events with its own vocabulary for actions, another exports only summaries, a third records file level events but not viewing, and a fourth, often the oldest and most sensitive, produces a report designed for its own administrators and nothing else. An auditor asking a simple question, who saw this customer's record last month, must translate that question into each system's dialect and accept that some dialects cannot express it.

Continue with identity. Access events are useful only if the person or process behind them can be named consistently. Across an estate, the same individual may appear under different account names in systems that predate single sign on, and service accounts often act for many humans at once. Where identity fragments, accountability fragments with it, and the audit becomes a set of partial stories that cannot be joined. NIST SP 800-207 builds its zero trust tenets on the same premise: access is granted per session, after authentication and authorization of the requesting identity, and the enterprise collects information about those requests to improve its posture, rather than inferring trust from network location (NIST, 2020).

Finish with coverage, the deepest problem. Third party portals, where staff and now agents handle claims, payments, and cases, belong to other organizations. Their logging, where it exists, is built for their customers in aggregate, and an individual enterprise typically cannot obtain event level records of its own users' activity inside them. Legacy internal applications present the mirror image problem: owned outright, but built before audit expectations existed, sometimes unable to record viewing at all. The result is that an audit assembled from application logs is most complete exactly where the risk is most ordinary, and thinnest where sensitive data is handled by exception.

What does a usable audit record need to contain?

NIST SP 800-53's audit and accountability family sets the working standard. Its control on the content of audit records expects records to contain information sufficient to establish what happened, and its companion controls address review and analysis of records, generation of records by systems in scope, and protection of the records themselves from unauthorized change (NIST, 2020). Translated into fields, an access event needs: the actor, in an identity that can be resolved to a person or a governed process; the action, in terms that distinguish viewing from copying, changing, or deleting; the object, meaning the record, file, or screen involved; the time; the origin, such as device or session; and the outcome, including whether a policy permitted, substituted, or blocked something along the way.

Two properties matter beyond the field list. The first is comparability: the same fields, with the same meanings, across applications, so that a reviewer can follow one person's or one agent's activity through a day that crossed five systems. The second is interpretability of the object. An audit trail for sensitive data should be able to show that a record was accessed without itself becoming a copy of the record. Where values are represented by tokens, the trail can demonstrate access exactly, which fields, which record, at what moment, while carrying nothing that needs protection in its own right. That property is easy to overlook when audit systems are designed, and expensive to retrofit.

Completeness is the third property, and the one audits actually test. A control that records nine of ten applications invites the question of what the tenth contains. NIST's framing of audit record generation, that systems in scope should be capable of producing records for defined events, makes coverage a design requirement rather than a hope (NIST, 2020).

How do unified audit logs solve part of the problem?

Microsoft's Purview Audit is the reference example of the normalization strategy executed well. Microsoft's documentation describes audit search over a unified log in the Purview portal, with parameters including date range, activity types, record types, users, files or sites, and workloads (Microsoft, 2025). The record structure behind those parameters is the point: activities performed in Exchange, SharePoint, OneDrive, Teams, and Entra ID are written into one repository with shared fields, so an investigator searches once, across workloads, by person or by object, and receives a coherent sequence rather than five unrelated extracts.

For the Microsoft portion of an estate, this changes auditing from archaeology into review. Questions that would take days of per system requests become searches. Retention is centrally managed, the search interface distinguishes friendly activity names from operation names so both analysts and auditors can work in it, and results can feed the recurring review that NIST's guidance expects (Microsoft, 2025; NIST, 2020).

The pattern generalizes beyond one vendor. Wherever an organization can impose a common record shape, whether through a platform's unified log or through disciplined forwarding into its SIEM with normalized fields, the audit gains the same properties: one vocabulary, one identity model, one retention story. NIST SP 800-92 describes that work as log management, the generation, transmission, storage, analysis and disposal of log data across an organization's systems, and treats a consistent log management infrastructure as the foundation for the analysis that follows (NIST, 2006). The work is unglamorous plumbing. It is also most of what makes cross application auditing possible at all, and it should be completed for the systems that support it before anyone complains about the systems that do not.

Where do unified logs stop?

The boundary is drawn by the platform's own estate. A unified log unifies what its vendor's services emit (Microsoft, 2025). The insurance portal, the banking platform, the government filing site, the niche case system bought by one department: none of these write into it. Neither does the older internal application whose vendor disappeared years ago. An estate's sensitive data does not respect that boundary; in many organizations the most sensitive handling happens in exactly the outside systems, because that is where claims, payments, and regulated submissions are processed.

A second boundary is the kind of event recorded. Platform audit logs record what the platform can see: file accessed, message sent, label changed. When an AI agent performs work, the security relevant events are of a different kind: which values were placed in the agent's context, which steps it attempted, which consequential actions a person approved. A platform log can show that a session occurred. It cannot show what the agent read on each screen, because that reading happened in the agent's working layer, not in the platform. Expecting the unified log to cover agent activity is a category error that will produce confident, incomplete audit reports.

Recognizing the boundary is not a criticism of unified logs; it is the precondition for designing the complement. The territory outside the platform estate, and the activity layer where agents work, each need a source of records of their own.

What does the audit trail look like when the work itself is recorded?

The complement is to record activity where the work is performed. In RedactSure's published design, supervised AI co-workers carry out browser workflows across an organization's existing applications, worked as rendered, without per application integration. The audit consequence follows from the architecture: because the work passes through one governed layer, that layer can keep one record of it. The company states that every screen as tokens, every action, and every approval with a name is held in its AI Control Record, and that the record can be exported to the customer's SIEM.

An auditor reading that record finds that its properties map to the field list above. The actor is identified, and for consequential steps the approving individual is named, so accountability attaches to people rather than to a generic agent identity. The object of each access is identifiable screen by screen, in token form, so the trail proves which records were presented without reproducing their sensitive values. The sequence is continuous across applications, because it follows the workflow rather than any one system, so the cross application question that defeats per system logs, what happened to this case as it moved through four applications, is the record's natural shape.

The limits deserve the same clarity. This trail covers governed agent workflows; it does not audit human activity in the same applications, nor agent activity outside the design, and RedactSure describes deployments as in pilot. The trail also depends on the governed layer being the actual path of the work: an agent operating outside it leaves no trace in it, which is an argument for making the governed path the only practical path for sensitive workflows, not a flaw in the record itself.

How should an organization run this audit as a practice?

Step Practice Why it matters
Inventory List applications where sensitive data is accessed, with each one's logging capability Defines the audit's true scope and its known holes
Normalize Adopt common fields for actor, action, object, time, origin, and outcome Makes records from different sources reviewable together
Unify what can be unified Use platform unified logs and disciplined SIEM forwarding Converts the supported estate from extracts into a sequence
Record the work layer Capture agent activity, including approvals, where workflows run Covers portals, legacy systems, and agent specific events
Review on a cadence Sample access events routinely, with named reviewers Satisfies the review expectation and finds drift early
Test the audit Run known access events and confirm they appear, correctly, in the trail A trail that has never been tested is an assumption

The final step is the one most often skipped and the one auditors respect most. Periodically, perform a small set of known accesses, including one through an agent workflow that ends in an approved consequential action, and then find each event in the assembled trail. Every event that is missing or malformed marks a place where the audit's claims exceed its evidence. NIST's guidance expects audit review to be an operating activity (NIST, 2020); testing the trail is how an organization knows the activity rests on records that exist.

Where does RedactSure sit?

For agent workflows in the second problem, the portals, legacy systems and cross application sequences that no platform log covers, RedactSure's AI Control Record is the design to apply. AI co-workers do real work across an organization's applications inside a governed environment, with no per-application integration and no change to user permissions. Every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, so the model works with ACCT_001 and PATIENT_001 rather than the values themselves. The Planner sets what is tokenized and what the agent may do on each screen; a named person confirms that policy and approves every payment, submission and record change.

Following a single workflow across applications, the AI Control Record holds every screen as tokens, every action, and every approval with a name, and exports to the customer's SIEM alongside platform logs rather than replacing them. An auditor asking who saw a particular record and what was done with it can follow the agent's sequence in tokens, with each consequential step tied to its named approver. Keys stay with the customer, the model is swappable, and deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on NIST SP 800-53 Rev. 5 (official guidance, 2020) for audit record content, review, and generation expectations; NIST SP 800-92 (official guidance, 2006) for log management practice; NIST SP 800-207 (official guidance, 2020) for the per session access and identity premise; and Microsoft's published documentation for Purview Audit search and the unified audit log (vendor documentation, 2025). All sources were read as of October 13, 2026. Microsoft's materials are cited for what they state about the platform's intended behavior, and the characterization of the unified log's boundary reflects the workloads Microsoft documents as covered.

No hands-on testing of Microsoft Purview Audit or of any other named product was performed. Vendor features, covered workloads and search parameters change with releases; the page carries its date and is revised when the documentation changes. RedactSure's record keeping is described only in the terms the company publishes, including its pilot status, and no record from any deployment was examined. No application estate was audited, and no customer, prospect or specific organization is described; statements about typical logging gaps are structural, based on the documented capabilities of the kinds of systems discussed, and the portal, banking and case system examples describe categories rather than any one organization.

Whether an audit program, a unified log or a work layer record meets an organization's regulatory or contractual requirements is a determination for its counsel, its assessor, and its own security and compliance officers, not for a research page. The practice table is a starting structure for that work, not a substitute for it.

What the record shows

Auditing sensitive data access across an enterprise is two problems wearing one name. The first, normalizing the records of systems that can produce them, is largely solved where platforms provide unified logs and where organizations impose common fields on the rest. The second, covering the portals, legacy systems, and agent workflows that sit outside every platform's remit, is solved only by recording the work where it happens, and the discipline remains the same either way: define the record, review it on a cadence, and test that known events appear. The one test an auditor can apply is to perform a known access, including one through an agent workflow that ends in an approved consequential action, and then find every event in the assembled trail. A trail that cannot pass that test is an assumption, whatever the platform dashboards say.

Frequently asked questions

Does a SIEM by itself solve cross application auditing?

A SIEM solves the aggregation problem: it gathers records into one place and makes them searchable together. It does not solve the production problem. Sources that emit poor records, or none, arrive at the SIEM as gaps, and no downstream tool can manufacture the missing events. The practice above pairs SIEM forwarding with attention to sources: common fields for systems that log, platform unified logs where they exist, and a work layer record for governed workflows that cross systems no platform log covers.

How should agent activity appear in an audit trail?

As a first class sequence of events in its own right: which screens were presented to the agent and in what tokenized form, which actions it took in each application, which consequential actions were put to a person, and who approved or declined them. That sequence should carry an identity that resolves to the run and its accountable owner, so an auditor can follow one piece of work across every application it touched. A single line saying an automated session occurred is not an audit trail for agent work.

What should an auditor ask about the applications with no usable logs?

Three things. Whether the organization has inventoried them, so the gap is known rather than discovered. Whether sensitive work in them can be routed through a layer that does record it, as governed workflow designs do for agent activity. And whether compensating review exists in the meantime, such as sampling the application's own reports or restricting who can use it for sensitive records. An acknowledged, owned gap with a plan is a defensible audit position; an unexamined one is not.

What fields should a cross application access record contain?

Six, drawn from NIST SP 800-53's audit content expectation: the actor, resolvable to a person or a governed process; the action, distinguishing viewing from copying, changing or deleting; the object, meaning the record, file or screen; the time; the origin, such as device or session; and the outcome, including whether a policy permitted, substituted or blocked anything. The fields must carry the same meanings in every source, or the records cannot be read together.

Can a platform unified audit log cover AI agent activity?

Not on its own. A unified log records what the platform's own services emit, such as a file accessed or a message sent, and only for the workloads the vendor documents as covered. An agent's security relevant events, which values entered its context, which steps it attempted and which actions a person approved, happen in the agent's working layer, so the platform log can show that a session occurred but not what the agent read on each screen.

Can an audit trail prove access without storing the sensitive values themselves?

Yes, when the trail records the object in token form. A record that shows ACCT_001 was presented on a given screen at a given moment, and that a named person approved the step that followed, proves which record was accessed without reproducing the account number. The trail then carries nothing that needs protection in its own right, which is easy to design in at the start and expensive to retrofit later.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.