Teams · Compliance

Access control evidence, produced by the access control itself

Most access evidence is assembled after the fact: screenshots, spreadsheet reviews, and a hopeful look at application logs. When authorization runs through Permit, the policy is versioned, enforcement is consistent, and every decision is already on record.

Book a demo Start free

Why logical access is the hardest control to evidence

Evidence is gathered after the fact
Screenshots and exports are collected weeks later, and show what access looked like on the day they were taken, not on the day in question.
Reviews without a source of truth
Access reviews compare spreadsheets to screenshots, because permissions live in a different database for every system.
Change history is scattered
Who changed a permission, who approved it, and when, is spread across tickets, commits, and admin consoles.
Auditors now ask about AI
Questions about what AI agents and automations can access have no existing control to point to.

How Permit supports your control environment

Permit does not replace your GRC program. It makes one of its hardest controls, logical access, enforceable and observable.

Policies as reviewed, versioned code
With GitOps enabled, policy changes from code or from the editor are committed to your Git repository with author and history.
One place to see who can do what
Roles, attributes, and relationships are defined centrally instead of per application, so an access review has one source.
An explained record of every decision
Decision logs capture user, action, resource, outcome, and a plain-English reason, and forward to your SIEM.
Approvals with a trail
Access requests and approvals run through embeddable workflows, so elevated access has a recorded sign-off.
The same controls for AI agents
Agents are authorized on a person’s delegated permissions and scoped consent, and their tool calls are logged like any other decision.

An audit question, already answered

Why could this person open this record? The decision log recorded it at the time. Illustrative data.

Example decisionallow

subject: user:priya@example-health.com (care coordinator)
action: read
resource: patient-record:PR-3317
reason: priya is on this patient’s care team at Clinic 4
logged: 2026-09-14 10:42 UTC by PDP in your VPC

Diagram: decision points stream records into decision logs that forward to a SIEM, while policy changes are tracked separately in Git history. — Every decision is logged with its reason and forwarded to your SIEM. Policy changes keep their own history in Git.

How a permission decision is made

IdentityA human, service, or AI agent, authenticated by your identity provider.
RequestCan this identity perform this action on this resource, right now?
Policy decision pointEvaluates RBAC, ABAC, and ReBAC policy with OPA or Cedar, in your network.
DecisionAllow or deny, returned to your code with the reason attached.
AuditEvery decision logged, explained, and forwardable to your SIEM.

The same five steps apply whether the caller is a person clicking a button or an agent calling a tool. Only the identity changes.

Audit logs built for the questions auditors ask

Who accessed what, why they were allowed, and who changed the rules. Permit records all three without anyone remembering to add logging.

Decision logs

Every access decision, recorded with its reason

Audit logs are generated by enforcement itself. Each check already knows the user, the action, the resource, and the tenant, so the log entry exists the moment the decision is made, not when someone reconstructs it later.

Audit logs record who did what, to which resource, and whether it was allowed.
Decision logs go further and record why the policy engine decided the way it did.
Filter by user, date, decision, and tenant in the dashboard, or query through the API.
PDPs write logs to standard output for any log pipeline, and the Logs Forwarder can ship them straight to Elasticsearch.

pdp values.yaml

pdp:
  logs_forwarder:
    enabled: true
    type: elasticsearch
    elasticsearch:
      host: logs.internal.example.com
      port: 9200
      index: permit-decisions

Change history

Who changed the rules, not only who used them

An access log without a change log answers half the question. Permit keeps a separate record of every administrative change to your authorization model.

The activity log records changes made in the dashboard: who changed which role, policy, or setting, and when.
The API log records changes made through the API, so automation is on the record too.
With GitOps enabled, every policy change is also a commit in your Git repository.
Policy guards limit who can change which policies in the first place.

Evidence on demand

Prove a change is safe, and let customers see their own trail

Logs are evidence for your auditors, and increasingly for your customers’ auditors too. Permit puts the same records to work in both places.

permit test run audit replays recent real decisions against a PDP running a proposed policy, and flags decisions that come out differently.
The Audit Log Replay API replays historical traffic for regression and load testing, available on request.
The Audit Logs Element embeds an activity trail in your own product, so your customers’ admins can review access without a support ticket.
Log retention can be extended on request when your policies call for a longer window.

Where Permit fits in common frameworks

These are the access control requirements Permit helps you implement and evidence. Your certifications and attestations remain your own.

Framework	What it asks for	How Permit helps
SOC 2, CC6.1 and CC6.3	Logical access security, with access granted and removed based on roles, least privilege, and segregation of duties.	Least-privilege policies with versioned change history, and decision logs showing enforcement.
ISO/IEC 27001:2022, A.5.15, A.5.18, A.8.3	Access control rules, provisioning and review of access rights, and restriction of access to information.	Explicit policies enforced on every request, with a central view of access for reviews.
HIPAA Security Rule, §164.312(a) and (b)	Access controls and audit controls for systems holding protected health information.	Fine-grained access to patient data, decision logs for audit, and a BAA available for regulated workloads.
PCI DSS v4.0.1, Requirements 7 and 10	Restrict access by business need to know, and log and monitor access to system components and cardholder data.	Need-to-know policies enforced per request, with every decision logged.
GDPR, Articles 25 and 32	Data protection by design, and appropriate technical measures to secure processing, including restricting access.	Purpose-scoped access to personal data, with decision points and data kept inside your own infrastructure.

Framework summaries are paraphrased for orientation and are not legal advice. Permit’s own service holds a SOC 2 Type II attestation covering Security, Availability, and Confidentiality.

In their words

“Permit.io has helped us a lot to have a well-designed authorization platform based on open standards that we didn’t have to design ourselves.”

Malcolm LearnerSenior Solution Architect, Signify Health

Read the docs, run the code

Documentation

Example projects on GitHub

Questions compliance teams ask

Does using Permit make us SOC 2 or ISO 27001 compliant?

No tool does that on its own. Permit helps you implement and evidence the logical access controls those frameworks test, such as least privilege and access logging. Your controls and your audit remain your own.

Can we review Permit’s own SOC 2 report?

Yes. Sections 1 and 2 of Permit’s SOC 2 Type II report are public in the Trust Center, and the full report is available on request.

How are policy changes tracked?

With GitOps enabled, policies are stored as code in your Git repository, and changes from code or from the editor are committed with author and history. Policy guards control who may change what.

What does a decision log contain?

The identity, the action, the resource, the outcome, the policy that applied, and a plain-English explanation of why.

Can audit logs go to our SIEM or log archive?

Yes. PDPs write audit logs to standard output, so any log pipeline can collect them, and the Logs Forwarder can ship them to Elasticsearch. Retention inside Permit can be extended on request.

Does Permit sign a BAA?

Yes, for HIPAA-regulated workloads where applicable.

Bring your hardest permission problem.

Tell us what you are authorizing and where it runs. We come to the call with a model of how Permit would enforce it.

Book a demo Read the docs

SOC 2 Type II attestedSecurity, Availability, Confidentiality
Cloud, hybrid, or on-premDecisions run in your network
Every decision loggedExplained, and forwardable to your SIEM
Built on open standardsOPA, Cedar, and OPAL

Review our security program in the Trust Center

Framework

What it asks for

How Permit helps

SOC 2, CC6.1 and CC6.3

Logical access security, with access granted and removed based on roles, least privilege, and segregation of duties.

Least-privilege policies with versioned change history, and decision logs showing enforcement.

ISO/IEC 27001:2022, A.5.15, A.5.18, A.8.3

Access control rules, provisioning and review of access rights, and restriction of access to information.

Explicit policies enforced on every request, with a central view of access for reviews.

HIPAA Security Rule, §164.312(a) and (b)

Access controls and audit controls for systems holding protected health information.

Fine-grained access to patient data, decision logs for audit, and a BAA available for regulated workloads.

PCI DSS v4.0.1, Requirements 7 and 10

Restrict access by business need to know, and log and monitor access to system components and cardholder data.

Need-to-know policies enforced per request, with every decision logged.

GDPR, Articles 25 and 32

Data protection by design, and appropriate technical measures to secure processing, including restricting access.

Purpose-scoped access to personal data, with decision points and data kept inside your own infrastructure.

Questions compliance teams ask

Does using Permit make us SOC 2 or ISO 27001 compliant?

Can we review Permit’s own SOC 2 report?

Yes. Sections 1 and 2 of Permit’s SOC 2 Type II report are public in the Trust Center, and the full report is available on request.

How are policy changes tracked?

With GitOps enabled, policies are stored as code in your Git repository, and changes from code or from the editor are committed with author and history. Policy guards control who may change what.

What does a decision log contain?

The identity, the action, the resource, the outcome, the policy that applied, and a plain-English explanation of why.

Can audit logs go to our SIEM or log archive?

Yes. PDPs write audit logs to standard output, so any log pipeline can collect them, and the Logs Forwarder can ship them to Elasticsearch. Retention inside Permit can be extended on request.

Does Permit sign a BAA?

Yes, for HIPAA-regulated workloads where applicable.

Access control evidence, produced by the access control itself

Why logical access is the hardest control to evidence

Evidence is gathered after the fact

Reviews without a source of truth

Change history is scattered

Auditors now ask about AI

How Permit supports your control environment

Policies as reviewed, versioned code

One place to see who can do what

An explained record of every decision

Approvals with a trail