NIST Sp 800-53 Au-2 Au-12 Audit Logging Controls
The nist sp 800 53 au 2 au 12 audit logging controls require teams to define and record system events. Engineering teams meet these rules by logging who ran each command and when it happened. Security managers need clear records across all databases, servers, and cloud tools. Control AU-2 tells you to pick which events to track across your systems. Control AU-12 requires your systems to create those logs when events occur. Together, they form the base of federal security audits. What nist sp
NIST 800-53 + K8s Audit Logging: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The nist sp 800 53 au 2 au 12 audit logging controls require teams to define and record system events. Engineering teams meet these rules by logging who ran each command and when it happened.
Security managers need clear records across all databases, servers, and cloud tools. Control AU-2 tells you to pick which events to track across your systems. Control AU-12 requires your systems to create those logs when events occur. Together, they form the base of federal security audits.
What nist sp 800 53 au 2 au 12 audit logging controls require
Under AU-2, your team must write down a clear list of loggable events. This list covers user logins, role changes, data reads, and admin actions. You must also state why each event matters for security checks. Leaders review and update this event list on a set schedule.
Under AU-12, your tech stack must record those chosen events in real time. Each log entry needs a timestamp, the user identity, and the event outcome. Auditors check that these records cover every server, container, and database in scope. This same log evidence also supports FedRAMP, SOC 2 Type II, ISO 27001, HIPAA, GDPR, PCI DSS, and SOX.
Many teams fail audits because they use shared database accounts or static keys. When five engineers share one admin login, AU-12 logs cannot name the real person. Auditors will flag this gap right away during an inspection. You must tie every single query or command to one human identity.
Why identity setup and access reviews need runtime logs and masking
Static role lists only show who can log in to a system. They do not show what a user did after logging in. To pass AU-2 and AU-12 checks, managers need runtime command logs. These logs capture the exact query or script a user ran.
Runtime logs also make quarterly access reviews much faster and more accurate. Managers can compare assigned roles against real activity logs from the past ninety days. If an engineer never uses a prod role, you can remove that permission. This step keeps your permission footprint small and safe.
NIST 800-53 + K8s Audit Logging: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, capturing full query results in logs or screens creates a new data risk. Raw database responses often hold private data like emails, phone numbers, or card numbers. If an engineer queries a user table, sensitive values can spill into local tools. Response masking fixes this issue by rewriting matched fields in results before delivery.
With response masking in place, teams can fix bugs while protecting national IDs. Auditors see both complete command logs under AU-12 and strong data privacy controls. You get full visibility into every action without exposing raw customer secrets.
How to build an audit logging workflow that passes inspection
Start by mapping every data store and server that holds sensitive records. Write down the exact admin commands and data reads that fall under AU-2. Next, link your central identity provider to every database and server login. Make sure no engineer uses a shared password or unmonitored key.
Send all runtime command logs to a central store that users cannot edit. Set up alerts for failed logins, schema drops, or bulk data reads. Test your log pipeline each quarter to make sure no events drop. When auditors arrive, you can pull clean reports by user, date, and resource.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the main difference between NIST AU-2 and AU-12?
Control AU-2 is the planning step where you decide which security events to track. Control AU-12 is the action step where your systems generate those audit logs.
How do shared database accounts break AU-12 audit rules?
Shared accounts hide which person ran a specific query or command. AU-12 requires logs to link every action to one unique user identity.
How does data masking help during security audits?
Data masking rewrites matched fields like emails, phone numbers, or card numbers in query results. This keeps sensitive data out of local screens and logs during daily work.