3.3.2 — Trace Every Action

The One-Liner

If the assessor picks a random log entry and asks “who did this?” — you need a name, not a shared account.

What It Says

Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.

What It Actually Means

Every action in your CUI environment must be attributable to a specific named individual. This is accountability — the ability to answer “who did this?” for any event in any log.

What this requires in practice:

1. Unique accounts per person. No shared logins, no generic “admin” accounts, no team mailbox credentials used for system access. Every human gets their own identity.

2. Service accounts with owners. Automated processes generate actions too. Each service account must be tied to a documented owner — a named person responsible for what that account does.

3. Sufficient log detail. Audit records must capture the user identity (not just an IP address) for every action. If your logs show “10.0.1.42 accessed file.docx” but not which user was on that machine, you can’t trace the action.

4. Nonrepudiation. Users cannot plausibly deny performing an action. If three people share a password, none of them can be held accountable — and you’ve failed this requirement.

This is the complement to 3.5.1 (unique identification). That requirement says everyone gets a unique ID. This requirement says every action is logged under that ID so you can always trace back.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Is audit record content defined to support tracing actions to individual users?	Records capture user identity (UPN/username), not just IP or machine name
2	Do audit records contain the defined content?	Sample any log — every action entry shows a unique individual identifier

---

What to Have Ready on Assessment Day

Documents they’ll review: Audit and accountability policy; procedures addressing audit record content and event types; system security plan; system configuration settings showing per-user logging; sample audit records; reports of audit findings; system incident reports

People they’ll talk to: Personnel with audit and accountability responsibilities; information security personnel; system or network administrators

Live demos they’ll ask for: “Show me a log entry and tell me exactly who did this.” “Show me your VPN logs — can you trace a session to a named user?” “Demonstrate that each user has unique credentials.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Pick a random action in your audit log — who performed it?”
• “Are there any shared or generic accounts in your environment?”
• “Show me your VPN logs. Can you trace a remote session to a specific person?”
• “If an unauthorized file download happened at 2 AM, could you determine exactly who did it?”
• “How do you handle service accounts — can actions by automated processes be traced to a responsible person?”
• “Does your system prevent users from denying they performed a specific action?”

Real-World Example

A 45-person defense sub requires unique Entra ID accounts for every user. VPN sessions are logged with the user’s UPN, source IP, and connection timestamps. The CUI file server logs all access under the authenticated user’s identity. When the assessor points to a file access record from the previous week, the IT manager immediately identifies it as a specific engineer accessing a project document during work hours. Service accounts follow a naming convention ([email protected]) and each has a documented owner. The assessor picks the backup service account and the team shows the documentation: owner is the DBA, created March 2024, reviewed quarterly. No shared accounts exist anywhere in the environment — a quarterly access review comparing Entra ID accounts against the HR active list confirms this.

---

Where Companies Trip Up

Shared accounts. Three engineers share “[email protected]” for server management. The assessor asks who changed a firewall rule last Tuesday and nobody can answer. Every person gets their own admin account — even if they all have the same privileges.

VPN without user identity. VPN logs show IP addresses but not which user authenticated. Configure your VPN to log the authenticated username for every session.

Service accounts without owners. An automated backup runs under “svc-backup” but nobody can say who’s responsible for it. Every service account needs a documented owner who reviews its activity.

Logs missing user fields. Application logs capture “transaction completed” but not which user triggered it. If the application can’t log the authenticated user, you either fix the application or add a compensating control that correlates the action with authentication logs.

---

How to Talk About This

To a CEO or Board

Every action in our environment is traceable to a named individual. If an incident occurs, we know exactly who did what and when. No anonymous activity, no shared accounts, no ambiguity.

To an Engineering Team

Unique Entra ID accounts per user — no exceptions. Service accounts: naming convention svc-[app]-[function], documented owners, quarterly review. All logs capture UPN. VPN sessions logged with user identity. Quarterly access review: Entra accounts vs. HR active list. No shared credentials anywhere.

---

Connected Requirements

Requirement	Why it matters here
3.5.1 — Prove Who You Are	Provides the unique identities this requirement traces actions to
3.3.1 — Log Everything	Creates the audit records that contain user identity
3.1.7 — No Shared Accounts for Admin	Prevents the shared privileged accounts that destroy traceability
3.3.9 — Limit Who Manages Logs	Ensures the audit trail itself can’t be tampered with by the people being logged

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: AU.L2-3.3.2 | SPRS Weight: 3 points | POA&M Eligible: No