Entra Audit Logs Retention

Entra audit logs retention defines how long your Microsoft cloud directory stores identity event history. Engineering teams meet audit rules by sending these directory events to long-term storage accounts.

Native directory storage holds sign-in events and role changes for a short time window. Security standards require teams to keep access records for several months or multiple years. Planning your log pipeline early stops data gaps before an external auditor arrives.

What auditors check in entra audit logs retention

Auditors review identity records to verify that access rules work over the whole review period. Frameworks like SOC 2 Type II, ISO 27001, and HIPAA demand clear historical trails. Teams working under GDPR, PCI DSS, SOX, and FedRAMP face similar record-keeping rules.

Assessors ask for proof of who joined the team and who changed directory roles. They also check when admins granted high-level permissions and when old accounts lost access. If your native portal deletes old events, your team fails the evidence check.

To fix this, security engineers route directory logs to an external archive right away. Teams often send event streams to cloud storage buckets or a central log platform. Once the logs land in storage, admins lock the files to prevent changes.

Time-based retention policies keep those locked files safe until the legal hold period ends. Teams also restrict who can read the archive by assigning strict reader roles. This setup proves to auditors that the historical event trail is complete and untouched.

Why directory logs need runtime command logs and masking

Directory logs show when an engineer signs in and which group roles they hold. Still, directory events never show what that engineer ran inside a database or server. Auditors and security managers need both identity records and runtime action logs.

Periodic access reviews become much easier when managers see real command and query history. If an admin holds a database role but runs zero queries, you can remove it. Runtime logs tie each SQL query or shell command to a specific user identity.

Capturing every query and command helps with audits, but it can expose sensitive data. Query results often contain personal details like emails, phone numbers, card numbers, or national IDs. Storing raw query outputs in your log archive creates a new privacy risk.

Response masking solves this problem by rewriting matched fields in results before anyone reads them. When an engineer runs a query, the masking rule replaces card numbers with safe tokens. The audit log records the exact action without storing raw emails or national IDs.

How to set up a clean audit log workflow

Start by writing down every compliance rule that applies to your business this year. Map out the exact retention window required by your longest audit framework. Next, set up automatic log routing from your identity directory to your archive bucket.

Test your archive every quarter by pulling sample records from six months ago. Check that the logs show both the directory sign-in and the runtime database commands. Verify that response masking rewrites phone numbers and emails across your live query results.

Finally, document this architecture in a short guide for your compliance assessors. Clear docs speeds up audit interviews and keeps your engineering team focused on building product.

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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.

Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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

Why is native directory log storage not enough for compliance audits?

Native directory storage removes event history after a brief default window. Most security frameworks require teams to keep audit evidence for at least one full year. Exporting logs to external storage keeps you ready for annual reviews.

What events should teams export from their identity directory?

Teams should export all user sign-in logs, directory audit logs, and provisioning events. Sign-in logs track who logged in, when they entered, and whether multi-factor checks passed. Audit logs track changes to users, groups, apps, and admin roles.

How do runtime logs support identity directory logs during an audit?

Directory logs only prove that a user logged in or received a role. Runtime logs record the exact commands and queries that user ran inside production systems. Together, they give auditors a complete view of user access and activity.

Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.

Related guides

• Azure Compliance Dashboard
• Azure Government Fedramp
• Best Practices for Program Quality Assurance Audit