NIST Sp 800-53 Audit Logging Au-2 Au-6
The nist sp 800 53 audit logging au 2 au 6 controls tell teams to define log events and review records often. Engineering teams meet this rule when they log every database query, command, and user action across their servers. Security managers use these two rules to spot bad actions fast. Control AU-2 asks you to pick which system events need logging. Control AU-6 asks you to check those logs on a set schedule. Together, they turn raw system data into clear audit proof. What nist sp 800 53 au
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 audit logging au 2 au 6 controls tell teams to define log events and review records often. Engineering teams meet this rule when they log every database query, command, and user action across their servers.
Security managers use these two rules to spot bad actions fast. Control AU-2 asks you to pick which system events need logging. Control AU-6 asks you to check those logs on a set schedule. Together, they turn raw system data into clear audit proof.
What nist sp 800 53 audit logging au 2 au 6 requires
Under AU-2, your team must write down a list of events to log. This list covers user logins, role changes, data reads, and admin commands. You must also state why each event matters for security. Auditors want to see this list in your written security policy.
Next, AU-6 requires your team to read and analyze those collected logs. You cannot just store records in a bucket and forget them. Your security team must look for odd patterns, failed logins, and unauthorized queries. When an odd event happens, your team must follow an alert plan.
Auditors ask for clear proof during an exam. They want to see sample logs that show who ran a command and when. They also ask for ticket records that prove your team reviews logs every week. Strong log evidence also helps teams meet SOC 2 Type II, HIPAA, GDPR, PCI DSS, SOX, ISO 27001, and FedRAMP rules.
Why identity setup and access reviews need runtime logs
Many teams start by setting up single sign-on and role rules. They also run quarterly checks to see who holds admin rights. Identity setup is a great first step, but it leaves a big gap. It shows who can enter a system, not what they did inside.
Shared database accounts make this problem much worse for managers. Five engineers might use the same admin role to fix a live bug. Native database logs will only show the shared role name. You cannot tie a bad query back to one specific person.
NIST 800-53 + K8s Audit Logging: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Runtime command and query logs fix this blind spot for good. When you log every action at the request level, you link each command to a real user identity. Your AU-6 review becomes much faster and more accurate. Reviewers see the exact SQL statement or shell command a person ran.
Response masking adds another layer of safety during these daily tasks. When an engineer runs a query, masking rewrites matched fields in results. It replaces emails, phone numbers, card numbers, and national IDs with safe placeholders. This keeps sensitive data out of local screens and audit logs alike.
How to build an audit review workflow for engineering
Start by mapping every production database, cloud server, and internal app. Pick the high-risk actions that must go into your AU-2 event list. Focus on schema drops, bulk data reads, permission grants, and secret reads. Keep the list tight so your team does not drown in noise.
Send all command and query logs to one central log store. Make sure each log entry holds a timestamp, user email, target name, and full command text. Set up automated alerts for high-risk actions like table deletes or after-hours logins. Review summary reports every week and save sign-off notes for your next audit.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the main difference between NIST AU-2 and AU-6?
Control AU-2 is about choosing which security events your systems must record. Control AU-6 is about reading, analyzing, and acting on those recorded logs on a regular schedule.
How often should teams review audit logs for AU-6?
NIST lets each team set its own review schedule based on system risk. Most engineering teams run automated alerts every day and do manual log reviews every week.
Do database queries count as auditable events under AU-2?
Yes, queries that read or change sensitive data are key events under AU-2. Auditors expect to see who ran the query, when it ran, and which target it hit.