Build a SOC 2 control mapping for your Auxot deployment

Why this matters

SOC 2 walkthroughs fail the same way every time. The auditor asks “show me how this control works,” and the team scrambles to find the right page, the right filter, the right screenshot. Twenty minutes of “let me pull that up” per control across forty controls is how a one-day audit becomes a one-week audit, and a calm conversation becomes a tense one.

Auxot satisfies a respectable fraction of common SOC 2 Trust Service Criteria controls directly:

• CC6 (Logical Access): Settings → Teams, Settings → API Keys, Settings → Multi-team isolation.
• CC7 (System Operations / Monitoring): Audit Logs (Jobs, Threads, Events), System Health.
• CC8 (Change Management): Agent description edits, tool-policy changes, provider swaps; all visible in Audit Logs → Events.

The rest you cover with external systems (your identity provider for SSO, your ticketing system for change approvals, your HR onboarding/offboarding flow). The mapping document is what tells the auditor which row lives where in advance, so the walkthrough becomes verification instead of investigation.

What this tutorial does not do: replace your auditor, draft your policies, or claim a clean opinion for you. It builds the evidence index (the spreadsheet auditors actually want) from what your Auxot deployment already has, plus honest pointers to the external systems that cover the rest.

Nothing satisfies a control on its own: you map the row, you name the owner, you verify the evidence still exists on the date of audit.

Quick start

1. Get the control list: your auditor’s spreadsheet, or the published Trust Service Criteria for the categories in your scope (Security is the default; Availability, Confidentiality, Processing Integrity, Privacy are add-ons).
2. Build the table skeleton: columns are Control ID, Plain-English summary, Auxot evidence (page / filter / file), Owner, Review cadence, Status (mapped / compensating / gap).
3. Map the high-confidence rows first: CC6 access controls and CC7 monitoring nearly always resolve to specific Auxot pages. Fill those before tackling anything ambiguous.
4. Mark compensating controls honestly: compensating control: SSO via [your IdP] is a real, auditable answer. unknown is not.
5. Save versioned + named owners: markdown table or context file titled SOC 2 mapping - YYYY-MM-DD. Every row has an owner; ownerless rows fail walkthroughs.

Done? A spreadsheet the auditor can open and verify in under a minute per row, plus a short gap list you can schedule against before the audit date.

The agent can do that?

1. Draft mapping from a pasted control list

Chat → Admin Agent:

Here is the SOC 2 control list my auditor sent: [paste]. For each control, propose: (a) which Auxot page or audit-log filter satisfies it, OR (b) `compensating control: external system needed; name the likely system (IdP, ticketing, HR)`. Do not invent. Mark anything you cannot determine as `needs human review`.

Why it’s non-obvious: Pasted control text beats memory. The agent maps each row to the canonical Auxot surface where it can be verified; you fill the gaps the agent flags as needs human review.

2. Flag controls without clear Auxot evidence

After the draft exists:

Mapping draft: [paste]. List every row where the evidence column says `compensating`, `unknown`, or `needs human review`. For each, suggest one external system the row likely lives in (Okta, Jira, BambooHR, etc.) so I can route to the owner of that system.

Why it’s non-obvious: Compensating controls are not failures; they are signals about which external systems your audit also depends on. Naming the system makes the routing obvious.

3. Pre-walkthrough Q&A per control

Pick the five controls in this mapping most likely to be sampled in a SOC 2 Type II walkthrough: [paste mapping]. For each, draft three bullets: (1) the question the auditor will probably ask, (2) the exact page or filter to open, (3) the one-sentence narrative the control owner should say while sharing the screen.

Why it’s non-obvious: Auditors do not memorize your stack. The owner needs a sentence to say and a screen to share. Rehearsing the top five rows cuts walkthrough time in half and removes the “let me pull that up” moments that erode auditor confidence.

Go deeper

Which Trust Services Criteria categories Auxot satisfies most cleanly

• CC6 (Logical Access): team membership, API keys, multi-team isolation, OAuth scopes. Settings → Teams, Settings → API Keys, Set up multi-team isolation, Create a shared Team API Key.
• CC7 (System Operations): continuous audit logs of every job, thread, and system event. View your audit logs, Trace a failing job end to end.
• CC8 (Change Management): agent description edits, tool policy changes, provider swaps (all logged). Pairs with Update your agents without breaking the team for the people-side of the change.

Which Trust Services Criteria categories Auxot does not cover directly

• CC1 (Control Environment): your org chart, code of conduct, board oversight. Lives outside Auxot.
• CC2 (Communication & Information): policies, training records, customer-facing security page. External, but Answer vendor security questionnaires from your own evidence feeds the customer-facing side.
• CC3 (Risk Assessment) and CC9 (Risk Mitigation): risk register and vendor-risk reviews. Your subprocessor inventory (Map your subprocessors for procurement) feeds part of CC9.
• CC4 (Monitoring Activities) and CC5 (Control Activities): internal audit cadences and policy enforcement. External, but Audit Logs (View your audit logs) supplies evidence.

Review cadence by control type

• Monthly: access reviews (CC6): who is on which team, which API keys are still in use.
• Quarterly: subprocessor inventory refresh (CC9), mapping document refresh, tool-policy review.
• On change: any time a new provider, MCP server, or team is added; update the affected rows the same day.
• Annually: policy documents (CC2), risk assessment (CC3), full mapping walkthrough with control owners.

Type I vs Type II

• Type I = controls exist as of a single date. The mapping is enough on its own; the auditor verifies you have evidence today.
• Type II = controls operated effectively over a period (typically 6–12 months). The mapping is the entry point; the auditor samples specific dates within the window and asks you to produce the evidence as it existed on that date. Audit Logs (View your audit logs) carry the historical record because they do not currently expire (Plan for retention and deletion requests → Retention).

Troubleshooting

• Auditor asks for a control you cannot find in Auxot. Mark it compensating and name the external system. Do not stretch an Auxot page to cover a control it does not actually satisfy; the walkthrough exposes that fast.
• Two controls point at the same Auxot evidence. Fine. Many controls overlap (e.g. CC6.1 and CC6.2 both touch logical access). Cite the same page twice with different narratives.
• Mapping was perfect last quarter, now half is wrong. Something changed (new provider, new team, new MCP server) and the mapping was not refreshed. This is what the quarterly review prevents.
• You added a context file and forgot to map it. Run power move 2 again after every Settings change worth noting.

Variations & edge cases

• Self-hosted vs hosted: self-hosted teams own additional CC6/CC7 rows (database access, backup access, infrastructure logs). Add a separate section to the mapping for infrastructure-layer controls.
• Multi-team setups (Business+): each team’s resources can be scoped separately (Set up multi-team isolation). The mapping should call out which controls inherit org-wide and which apply per team.
• Pre-audit dry run: schedule a 60-minute internal walkthrough one month before the real audit, using power move 3 to script the Q&A. Surprises surface where the team can still fix them.
• External penetration test: the test report is its own evidence row for CC4 / CC9. Reference it in the mapping; do not paste the full report.

Walkthrough

Step 1: Get the control list

Pull the auditor’s spreadsheet, or download the published Trust Service Criteria for the categories in your scope. Default scope is Security (CC1–CC9). Add Confidentiality, Availability, Processing Integrity, Privacy only if customers or contracts require them.

Step 2: Build the table skeleton

Columns:

Step 3: Map CC6 (Logical Access) rows

• Who has Auxot org admin? Settings → Teams shows the list.
• Who has API key access, and when was each key last used? Settings → API Keys; rotation cadence per Create a shared Team API Key.
• Are there separate teams for sensitive data? Set up multi-team isolation confirms scoping.

Step 4: Map CC7 (System Operations) rows

• What logs are captured? Audit Logs → Jobs (every agent run), Threads (every conversation), Events (every system action).
• Are errors monitored? Audit Logs → Events tab, severity filter Warning or Error.
• Is there a defined response process for incidents? Cross-link to your internal runbook; Trace a failing job end to end covers the technical investigation path.

Step 5: Map CC8 (Change Management) rows

• Are agent changes logged? Audit Logs → Events shows every description edit, tool policy change, and provider swap with timestamp and actor.
• Is there an approval process for changes? Update your agents without breaking the team for the announcement side; reference your ticketing system for approval evidence.

Step 6: Mark compensating controls honestly

For every control Auxot does not satisfy directly:

• Name the external system that does (IdP, ticketing, HR, code-of-conduct doc).
• Note the owner of that system.
• Mark status as compensating.

Do not stretch an Auxot page to cover a control it does not actually satisfy. The walkthrough exposes that fast and damages credibility on rows you genuinely have evidence for.

Step 7: Save versioned and route to owners

Save the mapping as a context file titled SOC 2 mapping - YYYY-MM-DD. Include the footer:

Mapping owner: [name]
Last reviewed: YYYY-MM-DD
Review cadence: quarterly

Share the file with every named owner. Schedule the quarterly review on the calendar so the document does not go stale between audits.

What’s next

• → Map your subprocessors for procurement. The CC9 risk row reads from this inventory.
• → Hand off the audit narrative when your compliance lead changes. This mapping is part of the same handoff packet as the audit narrative; both need to survive an ownership change with the reasoning behind each compensating-control choice intact.
• → Answer vendor security questionnaires from your own evidence. The same evidence muscle, different audience (customer procurement vs your auditor).
• → Plan for retention and deletion requests. Retention-policy text supports CC7 and Privacy criteria.
• → Run a data privacy review before you ship. Privacy-criteria mappings overlap with DPIA work.
• → View your audit logs. The page auditors will open most during Type II walkthroughs.
• → Set up multi-team isolation. Scoping evidence for CC6.
• → Red-team your agents against prompt injection. Adversarial testing receipts strengthen CC7 monitoring rows.

Reference

• Pages in Auxot: Settings → Teams, Settings → API Keys, Settings → Agents, Audit Logs (Jobs / Threads / Events tabs)
• Mapping columns: Control ID, Plain-English summary, Auxot evidence, Owner, Review cadence, Status (mapped / compensating / gap)
• Trust Services Criteria categories Auxot satisfies most cleanly: CC6 (Logical Access), CC7 (System Operations), CC8 (Change Management)
• Trust Services Criteria categories that need compensating controls: CC1 (Control Environment), CC2 (Communication), CC3/CC9 (Risk), CC4/CC5 (Monitoring & Control Activities)
• Refresh cadence: monthly (access), quarterly (mapping + vendor), on change (new provider/team/MCP), annually (policy + risk)
• See also: Map your subprocessors for procurement, Answer vendor security questionnaires from your own evidence, Plan for retention and deletion requests, View your audit logs, Set up multi-team isolation, Trace a failing job end to end