How authentik supports SOC 2 logical access controls
If you are preparing for a SOC 2 examination, the identity layer is where much of your CC6.1 to CC6.3 evidence will come from. authentik can help with three parts of that work: central single sign-on and MFA for in-scope applications, provisioning and deprovisioning that moves people in and out of access, and an event log that records authentication and administrative activity. It does not decide which access is appropriate, who approves a request, how often access is reviewed, or whether your controls are designed and operating effectively. Those remain organizational responsibilities, and the auditor forms the opinion. DeployOpen plans, configures and documents the system and prepares the evidence an examination will look at. We do not issue reports or certifications, and the scope of the examination is set by your organization and your auditor.
Start by agreeing on the in-scope systems with your auditor, because every application that holds customer data and is not behind authentik will be a gap an auditor can question. For each in-scope application, confirm whether it supports OAuth2/OIDC, SAML, LDAP or a proxy outpost, since that determines whether sign-in can be centralized and whether MFA is enforced at the identity provider or only at the application. Confirm the protocol support for each application with its vendor and in your own test environment rather than assuming it. Decide early who administers authentik itself, and keep those administrator accounts separate from everyday user accounts so that privileged changes stand out in the logs.
Plan the evidence before the examination window opens. Export and retain the authentication and administrative event logs your chosen deployment produces, and confirm retention and forwarding settings with your operations team, since the audit log needs to cover the period the auditor samples. Document the joiner and leaver process as a written procedure that names who requests access, who approves it, and what triggers removal, then test that the procedure produces matching tickets and changes in authentik. Access reviews are a management activity: authentik can list group and application membership for reviewers, but the reviewer's decisions, dates and follow-up must be recorded by your organization. Ask your auditor which sample populations and review formats they expect before you build the reports.
Mapping CC6.1, CC6.2 and CC6.3 to authentik capabilities and configuration
This table maps the CC6.1, CC6.2 and CC6.3 criteria, plus CC6.6 for MFA and boundary protection, to authentik capabilities and the configuration an assessor will expect to see. Read each row as a control question: what the criterion asks, what authentik provides, and what your team must build and document. The main takeaway is that authentik supplies the enforcement points, while joiner, leaver and review records remain your responsibility.
| Criterion and points of focus | authentik capability | Configuration to build |
|---|---|---|
| CC6.1: Logical access security software, infrastructure and architectures that protect information assets | Central identity provider for in-scope applications through OAuth2/OIDC, SAML, LDAP, proxy and SCIM provider types. | Inventory each in-scope application and its protocol. Create one provider and application per system, and name the authoritative identity source. |
| CC6.2: Register and authorize new users before credentials are issued or access is granted | Enrollment flows control how accounts are created. SCIM provider types can push accounts to downstream applications that support it. | Restrict enrollment to invitations or approved sources. Record the approval in your ticketing system, and keep that record linked to the account. |
| CC6.2: Remove credentials once access is no longer authorized and prevent use of invalid credentials | Deactivating a user blocks new sign-ins to bound applications. Confirm how existing sessions and tokens end in your version. | Write a leaver runbook covering deactivation, group removal, session revocation and downstream SCIM deprovisioning. Test it on a staging user. |
| CC6.3: Grant, change or remove access by role, with role-based access structures and periodic role review | Groups carry role membership. Application bindings and policies decide which groups may launch each application. | Define roles as groups per application. Bind each application only to the groups allowed. Export group membership for each review cycle. |
| CC6.3: Least privilege and segregation of duties for administrative and business roles | Separate admin groups restrict who can manage authentik itself. Enhanced audit logging is listed as an Enterprise feature on the pricing page. | Keep administrator membership in a small group. Require separate accounts for administration and daily work. Confirm admin role options in your version. |
| CC6.6: Protection against threats from outside the system boundary, including MFA and protection of authentication credentials | MFA stages in authentication flows, applied through policies per application. Proxy outposts protect applications that cannot speak OIDC or SAML. | Attach an MFA stage to every in-scope application. Place proxy outposts behind your reverse proxy. Confirm which second factors your version supports. |
Which in-scope systems authentik can front
Applications that support OpenID Connect or SAML 2.0 are the strongest fit for SOC 2 logical access evidence. authentik acts as the identity provider through its OAuth2/OIDC and SAML provider types, so sign-in, MFA enforcement and session decisions are made in one place and logged centrally. Confirm the protocol support of each application against its own documentation, since many products support only one of the two and some restrict role mapping to a paid tier.
- Application-side settings: Confirm whether the app accepts external groups or claims for role assignment, or whether roles must be set locally.
- Certificate and key handling: Record who holds SAML signing certificates and when they rotate.
- Logout behavior: Test whether signing out of authentik ends sessions in the application, since a stale session can outlive a removed user.
- Attribute mapping: Document which claims map to which application roles so access reviews can read them.
For each application, record the protocol, the authentik provider and application objects, and the test result for a denied user.
Some systems can only authenticate against an LDAP directory and cannot speak OIDC or SAML. authentik provides an LDAP provider so these clients bind against it, which keeps identities and group membership managed in one directory. Because LDAP binds carry a password rather than a browser-based redirect, MFA behavior and session timeouts differ from the SSO routes, and the reviewer should check both explicitly.
- Bind accounts: Limit the service accounts used for LDAP binds, document their scope, and confirm they cannot sign in interactively.
- MFA coverage: Confirm whether MFA applies to LDAP clients in your configuration, and what the client does when a second factor is required.
- Group-based access: Map LDAP groups to the application's roles and record the mapping for access reviews.
- Session lifetime: Check how long the client keeps a session after a user is disabled.
Confirm with the application vendor whether it caches LDAP results, since cached membership can keep a removed user's access alive until the cache expires.
Applications that cannot speak OIDC, SAML or LDAP can sometimes be protected with authentik's proxy provider, which runs as an outpost behind a reverse proxy. The proxy checks the session before traffic reaches the application, so the application itself does not need to change. This route is useful for internal web tools, but it protects only the path through the proxy. Direct access to the application's origin, its API or its local login page can bypass the control unless the network prevents it.
- Network path: Confirm the application accepts traffic only from the reverse proxy, not directly from users or other hosts.
- Header trust: Verify that the application trusts identity headers only from the proxy and that clients cannot forge them.
- Non-browser clients: Identify API clients and scheduled jobs that bypass the browser flow and decide how they authenticate.
- Outpost health: Monitor outpost availability, since a failed outpost can block users or, depending on configuration, leave gaps in coverage.
Test the protected route and the direct route separately and keep both results as evidence.
SaaS applications are where joiner, mover and leaver handling is most visible to an auditor. authentik can provision accounts into a SaaS application over SCIM, and the Google Workspace and Microsoft Entra ID integrations are documented provider types. The pricing page lists the Google Workspace and Entra ID integrations, and mTLS, as Enterprise features, so confirm the edition required before scoping these routes. Provisioning and sign-in are separate controls: a user removed from authentik may still hold an active local account in the SaaS application if deprovisioning is not configured.
- Edition check: Confirm which provider types your edition includes before committing to a provisioning design.
- Deprovisioning test: Remove a test user and confirm the SaaS account is disabled, not just unable to sign in.
- Admin accounts: Identify administrator accounts that exist outside SSO and record how they are protected.
- Plan requirements: Confirm with the SaaS vendor which plan tier allows SSO enforcement and SCIM.
Keep the provisioning log and the deprovisioning test result together, since they are the evidence for leaver handling.
Most applications keep a local account store, often including a built-in administrator, emergency login or API token. Those paths can bypass SSO entirely, and an auditor testing CC6.1 will ask how they are controlled. authentik can front an application only where the application's own login is disabled or restricted. The organization must decide, for each application, whether local accounts are removed, limited to break-glass use, or monitored, and must be able to show the decision.
- Inventory: List every local account, including vendor defaults and service accounts, for each in-scope application.
- Break-glass process: Define who may use an emergency account, when, and how the use is approved and logged.
- Password policy: Record the password rules for accounts that remain outside SSO.
- Restriction method: Decide whether the application setting, network rule or proxy path enforces the restriction.
Before scoping any application as fronted by authentik, confirm with its vendor whether local login can be disabled, and document the answer.
Configuring authentik for SOC 2 evidence
This sequence turns an authentik deployment into the access controls and records an auditor can sample against CC6.1 to CC6.3. Each step produces a configuration, a test result or a log that you can show for in-scope systems. Work through the steps in order, because the later evidence depends on earlier decisions about applications, groups and retention.
Deploy on a supported release line
Start with a version the project still patches. The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines receiving security fixes, and the project announces security releases at least 24 hours in advance, so your team can plan patch windows. Your platform team installs the release and records the exact version in your change log. The Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. For production, use a separately managed PostgreSQL, because the Kubernetes chart's bundled PostgreSQL is intended for demonstration and test environments only. The step is done when the running version and database location are written into your system description.
Define in-scope applications as providers
List every system that holds customer data or supports the service in scope. For each one, create an authentik provider and application using the protocol the system supports, such as OAuth2/OIDC, SAML or LDAP. Where a system has no native support, check whether the proxy provider fits, and confirm the approach with the application's vendor. Your application owner confirms which users and groups should reach each application. The output is an inventory that maps each in-scope system to its authentik application. This inventory becomes the population your auditor will ask about under CC6.1.
Enforce MFA by group or application
Configure authentication flows so that a second factor is required for the groups and applications in scope, starting with privileged users and remote access. Choose the factor types your policy allows, and confirm with each client which factors it supports, since LDAP and RADIUS clients handle second factors differently from browser sign-in. Test with a sample account from each group. The step is complete when a sign-in to each in-scope application prompts for a second factor and the test results are saved with the change record. This step supports the points of focus under CC6.6 that call for additional authentication.
Create group-based roles mapped to CC6.3
Build authentik groups that match job functions, then grant each application access through those groups. Avoid direct per-user grants, so that every access decision can be traced to a role. Keep administrative rights in separate groups, and make sure the people who approve access requests are not the people who grant them, which supports the segregation of duties described in CC6.3. Record the role matrix, a table listing each group, the applications it reaches and the role it holds, and have the owner of each application approve it. The step is done when the matrix exists, every in-scope application maps to at least one group, and a test user in a non-administrative group cannot open administrative functions.
Wire joiner and leaver processes
Connect your HR or ticketing trigger for new hires and departures to authentik so that account creation, group assignment and deactivation follow a documented path. Use the group structure from the previous step, and document which system is the source of truth for employment status. For leavers, the test is that a deactivated account cannot start a new session and loses group-based access to every in-scope application. For directories and SaaS targets, confirm with each vendor whether provisioning is supported and how removals are handled. The step is done when a test joiner and a test leaver run through the process and each action is recorded in your ticket system.
Set up event logging and retention
Confirm which authentication, authorization and administrative events authentik records, where they go and how long they are kept. The pricing page lists enhanced audit logging as an Enterprise-only feature, so ask the vendor what the edition you run keeps and whether it covers the events your auditor will sample, such as sign-ins, failed logins, MFA changes, group membership changes and application access. Forward logs to a store your team controls and set retention in line with your policy. Because PostgreSQL holds all configuration and data except uploaded files, include it in your backup plan. The step is done when a sample sign-in, a failed attempt and a group change each appear in the central store with a timestamp and user identifier.
Schedule and record access reviews
Run access reviews on a fixed cadence that your policy sets, and keep each review as a signed record. For each in-scope application, export the group members and their roles, have the application owner confirm or remove each entry, and apply the removals in authentik. Keep the export, the reviewer's sign-off and the related change tickets together. The review is complete when every removal traces to a leaver event or a role change and the signed record is stored where the auditor can request it. Confirm the cadence and the evidence format with your auditor before the first review, so the records match what will be sampled.
Evidence auditors sample from the identity layer
A SOC 2 auditor testing CC6.1 to CC6.3 samples evidence, not intentions. The cards below cover the records an authentik deployment produces for access granting, MFA, removal and review, and the owner and retention decision for each. Confirm retention periods and export methods for every record with your authentik version and your SIEM before the examination period begins.
Provider and application configuration exports
Keep dated exports of authentik providers, applications, flows and policies so the auditor can see how sign-in and MFA were configured during the period, not only today. Store exports under change control, with the person who approved each change recorded alongside it. Ask the auditor whether they want configuration as of the period start, the period end, or both, and confirm how your deployment exports configuration (manual export, configuration as code, or database snapshot) before you commit to a method. Config keys that are secrets should be excluded from exports and held in your secrets store.
Group membership and role history
Auditors sample who held access to an in-scope system and when that access was granted or changed, so group membership must be traceable over time, not only at a snapshot. Keep a dated history of group and role assignments, with the requesting manager and approver for each change. Decide who owns this record: usually the identity administrator maintains it, while the application owner confirms the roles are correct. Confirm whether your authentik version records membership changes in its event log or whether you need to capture snapshots yourself.
MFA enrollment and enforcement settings
Evidence for CC6.6 needs two things: the policy that requires a second factor for each application and group, and proof that users enrolled before they gained access. Keep the stage bindings for MFA on each flow, the list of enrolled authenticators per user, and any exceptions with their approvals. Ask the auditor how they will test exceptions, because an unapproved bypass is the most common finding. Confirm in your version how authenticator enrollment is logged, since that record is what proves enforcement.
Authentication and authorization event logs
Event logs show whether MFA was used and whether access was refused, which is what an auditor samples to test operating effectiveness across the period. Enhanced audit logging is an Enterprise feature on the authentik pricing page, so confirm whether your edition provides it before you rely on it. Forward logs to a central store with a retention period set by your log policy, and record who can read and who can delete them. Ask the auditor which events they will sample (successful logins, failed logins, policy changes) and confirm that each one is retained for the full period.
Deprovisioning tickets with timestamps
For leavers, the auditor compares the termination date in HR records with the time access was removed, so the ticket and the authentik event must agree. Keep the offboarding ticket, the disable or deactivation event for the user, and the removal of sessions and tokens, each with a timestamp from the same time source. Assign ownership to the HR-triggered workflow and the identity administrator who closes the ticket. Confirm whether your deployment disables accounts and revokes active sessions as separate actions, and record both if they differ.
Signed access review records
Periodic access reviews show that someone checked whether each person still needed access, which speaks to CC6.2 and CC6.3. Keep the review population exported from authentik on the review date, the reviewer's sign-off, and the list of removals or changes that followed. A review is only credible if the export matches what was actually active on that date, so store the export with its hash or a generated report reference. Assign the reviewer to the system owner, not to the administrator who configured the access. Ask your auditor how often they expect reviews and what sample size they will apply to them.
How joiner, leaver and access review evidence is built
CC6.2 requires the organization to authorize new users before credentials are issued and to remove those credentials once access is no longer authorized. authentik does not make that decision for you. It records and enforces what you configure: a user account, group memberships, and application assignments. The authorization itself happens outside authentik, usually in an approval ticket or HR workflow that names who approved the access, what they approved, and when. Before go-live, agree which system is the source of truth for joiners and leavers, and confirm with your auditor that the approval record, not the authentik entry, is what they will sample first.
The sample evidence auditors test depends on tying those external events to account changes inside authentik. For each joiner, keep a link between the approved request, the account created or invited, and the groups assigned at that moment. For each leaver, keep the disablement or deletion event and the time it happened compared with the termination date from HR. Confirm which authentik events are retained, how long your log pipeline keeps them, and whether they are exported off the instance so they survive a rebuild. Periodic reviews of group membership are the other half: export the membership of every group that grants access to in-scope applications, have the owner confirm each entry, and record the reviewer, the date and every removal made. Confirm the export format and retention with your auditor before the first review cycle.
The distinction between a Type 1 and a Type 2 report shapes how much of this evidence you need. A Type 1 report covers the system description and the suitability of control design as of a date, so a single, well-documented review may be enough. A Type 2 report adds an opinion on operating effectiveness over a period, so the joiner approvals, leaver removals and review records must exist for the whole observation window, not only at the end of it. Ask your auditor which report type and period apply, and plan the recurring review cadence and log retention around that period from the first day authentik is live.
What authentik does not cover for SOC 2
authentik supplies authentication, MFA, provisioning and event logs for CC6.1 to CC6.3, but several items an auditor will sample sit outside the product. Each card names a gap, who owns it, and what to confirm before the examination period starts.
System description and policies
The SOC 2 description of the system and the written access policies are management's responsibility. Under the AICPA 2018 description criteria (DC 200), management must describe the boundary, components and controls, and an authentik configuration export does not replace that narrative. Confirm who writes the description, which authentik groups and applications are named in it, and how policy changes are versioned and approved.
Authorization decisions and approvals
authentik enforces the group and policy bindings it is given, but it does not decide who should receive access or record a business approval. CC6.2 expects the organization to register and authorize users before credentials are issued. Confirm that a ticket or request system captures the approver, the requested role and the date, and that the authentik change is traceable to that record.
HR-driven lifecycle and certification
Joiner, mover and leaver events usually start in an HR system, and periodic access certification is a campaign with reviewer sign-off. authentik can act on directory and provisioning data, but a separate identity governance tool may be needed for HR triggers, recertification campaigns and evidence of reviewer decisions. Confirm where the authoritative employee record lives and who attests to each review.
Monitoring and incident response
Authentication events are only one input to security monitoring. CC6.6 and the wider common criteria also expect detection of threats to the boundary, alert handling and incident response, which sit in a SIEM, log platform or on-call process. Confirm which authentik events are forwarded, who triages failed-login and lockout alerts, and how responses are recorded for the auditor.
Enterprise-only features
Some integrations and controls are listed only on the Enterprise tier of the authentik pricing page, including Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. Confirm each item against current pricing before designing the control, because the open-source edition may not provide the same evidence. The licence for code under the enterprise directory is separate from the MIT licence that covers most of the repository.
The auditor's opinion
Only an independent CPA firm issues a SOC 2 report, and the opinion depends on the controls operating over the examination period. Implementation work can prepare systems, configuration and evidence, but it cannot guarantee a clean result or substitute for the auditor's sampling. Confirm the report type (Type 1 or Type 2), the examination period and the auditor's sample expectations early, and whether the report will be used by customers under its restricted-use terms.
Questions buyers ask about SOC 2 access controls with authentik
Is the open source edition of authentik enough for SOC 2 access controls?
The open source edition can provide SSO and MFA for in-scope applications, but you need to confirm whether your evidence needs depend on Enterprise-only features. The authentik pricing page lists enhanced audit logging, password history, and Google Workspace and Microsoft Entra ID integrations as Enterprise-only. If your auditor will sample audit records from a particular source, or your SaaS directories are Entra ID or Google Workspace, check those requirements against the edition before you design the control. The MIT-licensed code covers most of the repository, while the authentik/enterprise/ directory falls under a separate enterprise license, so confirm licensing terms with authentik before you commit to a design.
What cost drivers apply to an authentik SOC 2 access control project?
Costs come from three areas: the authentik license edition, the infrastructure that runs it, and the labor to design, integrate and document the controls. authentik publishes Enterprise pricing per user per month, plus a per-external-user charge, and Enterprise Plus starting at a published annual figure, so your license cost recurs and scales with headcount. DeployOpen does not publish prices. A quote follows from a written scope that lists applications in scope, integration types, the joiner and leaver workflow, the access review process and the evidence you need to produce. Ask for one-time work and recurring support to be itemized separately.
How long does it take to put authentik access controls in place for SOC 2?
Duration depends on how many applications must sit behind authentik, which integration types they need, and how mature your evidence process is today. An application that supports OIDC or SAML is usually simpler than one that needs a proxy or LDAP bind, and every provisioning connection to an HR system or ticketing tool adds testing time. Teams with no written access review procedure will spend time defining one before any tooling work begins. Ask for a timeline in the written scope that names each application and integration, and treat it as an estimate to validate once discovery is complete.
What does the organization need to provide for an authentik SOC 2 engagement?
The work depends on inputs from the people who own the systems and the data that proves access decisions were made. Expect to provide:
- Named application owners who approve access and confirm which systems are in scope
- HR records for hires, role changes and terminations, so joiner and leaver events can be matched to accounts
- Ticket or approval data showing who authorized each access grant and removal
- Access to your authentik instance, its logs and your existing directories for testing
- A sample period of operating records, such as review sign-offs and deprovisioning tickets, that an auditor can examine for a Type 2 report
Confirm with your auditor which sample period and record formats they expect before collection begins.
Can our internal team run authentik SOC 2 access controls without a partner?
Yes, an internal team can run these controls if it combines SOC 2 knowledge with identity engineering skills. The SOC 2 side requires understanding of the common criteria for logical access, CC6.1 to CC6.3, and how an auditor will test them, including the description of the system. The engineering side covers authentik providers, flows and policies, group-based access, provisioning and event logging. Many teams find the hardest part is the evidence process, not the configuration, because records must be retained and consistent across the sample period. A partner can provide the design, implementation and documentation as a fixed-scope engagement, while your team keeps ownership of the controls day to day.
How do authentik upgrades affect SOC 2 access control evidence?
Upgrades can change configuration, behavior and log output, so each upgrade should be treated as a change that you document and test against your controls. authentik's security policy lists the supported versions that receive security fixes and states that security releases are announced at least 24 hours in advance, which gives you a short window to plan a response. Feature releases and breaking changes need their own review, and the release notes should be read before you upgrade. Keep records of the version in use during each part of the sample period, the change ticket, and the test results, so an auditor can see that access controls operated consistently across the upgrade.
Does authentik itself make an environment SOC 2 compliant?
No. SOC 2 is an examination of the service organization's system and controls, and an independent CPA firm issues the report. authentik can support the logical access controls in CC6.1 to CC6.3, such as MFA, SSO and access removal, but the organization must design its policies, operate them consistently and retain evidence. DeployOpen prepares systems, controls and evidence for a compliance assessment, but does not issue audit reports or attestations. Ask your auditor which control descriptions and evidence they expect before the implementation is finalized.
How the SOC 2 scope and evidence plan are agreed
The SOC 2 scope and evidence plan is agreed in writing before any authentik configuration starts. DeployOpen engagements are fixed-scope, so the written scope sets out which systems are in, the deliverables for each, and the timeline. Before work begins, the plan maps each in-scope system (for example, the authentik server and worker, the PostgreSQL database, and each application signed in through authentik) to the CC6.1, CC6.2 and CC6.3 criteria it supports, and names an owner for each evidence source, such as the identity administrator for provisioning records or the application owner for quarterly access reviews. Confirm early whether the boundary includes the authentik outposts and any directory authentik reads from, because an unmapped system is usually where evidence gaps appear.
The auditor and management set the examination scope, not DeployOpen. Management decides which trust services categories and systems the SOC 2 covers, and the service auditor, a CPA firm, decides the procedures and issues the report. DeployOpen's role is to prepare the controls, configuration, logging and evidence so that the auditor can test them, and to document how each one is produced. DeployOpen does not issue audit reports, attestations or certifications. Ask your auditor, before scoping, which sampling populations they expect for joiners, leavers and access reviews, and whether they will accept authentik event exports as system-generated evidence.
Agree the plan's review points in the written scope too: who signs off the criteria mapping, when the evidence owners test their own extracts, and what happens if the auditor asks for a different period than the one planned. The period matters because a Type 1 report reflects control design as of a date, while a Type 2 report tests operating effectiveness over a period, so the evidence schedule depends on which report management is preparing for. Confirm the report type with your auditor before the plan is final.
How DeployOpen delivers SOC 2 access control work on authentik
DeployOpen plans, implements, hardens, documents and supports self-hosted authentik inside your own infrastructure, so the identity controls behind your SOC 2 logical access criteria run where your evidence lives. We prepare systems, controls and evidence for your assessment, but independent auditors issue the SOC 2 report.
How we scope
- Engagements are fixed-scope, with systems in scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the in-scope applications, the identity sources and the provider types each application will use.
- We record which CC6.1 to CC6.3 control points each deliverable supports, so the scope maps to what your auditor will test.
How we build
- We configure MFA, SSO, group-based role assignment and provisioning for the in-scope systems you named in the scope.
- We test joiner, mover and leaver paths in a non-production environment and record the results before cutover.
- We configure event logging and retention so access changes and authentication events can be pulled as evidence during sampling.
How we hand over
- You receive architecture, configuration and runbook documentation describing the access model, roles and deprovisioning steps.
- We document the access review procedure, including who reviews, how often, and what evidence each review produces.
- Handover includes a walkthrough of the evidence queries so your team can export samples for the auditor without us present.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing against your environment.
- Upgrade planning covers authentik release changes, so access controls keep working and documentation stays current with the running version.
- Your auditor's questions about controls can be answered with the configuration and logs we documented, and we confirm evidence gaps with you.
