O2 AI · Private beta
AI for SOC 2 evidence, with review boundaries intact
AI can help organize infrastructure evidence for SOC 2 work, but collecting records is different from evaluating a control or issuing an assurance report. When configured, the O2 AI Security and Compliance Agent can organize technical control and evidence context. It does not certify an organization or replace qualified assessment.
Define a focused evidence workflow with your reviewer
Begin with a specific evidence request and the systems, owners and period it covers. Examples to discuss include production access decisions, release approvals or infrastructure configuration records. These are pilot inputs, not a claim that every connector or evidence source is supported in O2 AI.
Agree how source records are obtained, which fields are retained, who can view them and what collection gaps look like. A document assembled by an agent should not be labelled complete when part of the requested system or period is missing.
| Record field | Purpose | Gap to expose |
|---|---|---|
| Source and collection time | Trace the record to the originating system | Unavailable or stale source |
| System and period | Identify what the evidence actually covers | Missing environment or interval |
| Control context | Explain why the record may be relevant | Unreviewed mapping or unsupported conclusion |
| Owner and review | Identify who checks relevance and sufficiency | Unassigned reviewer |
| Exceptions | Preserve failures and unresolved questions | Gaps hidden behind a completion badge |
| Handling rules | Agree retention, access and redaction | Sensitive data outside the agreed scope |
Use an access-decision example before expanding scope
For an illustrative temporary production-access request, collect the request, policy decision, approval and observed expiry or revocation result. Ask the reviewer to identify which records are relevant to the agreed evidence request. Retain missing or conflicting records rather than converting them into a passing conclusion.
A proposed mapping is a review aid. The appropriate control context, evidence period and sufficiency need agreement with your organizational owners and qualified assessor. This page is not a control checklist, an audit opinion or an assurance that a particular organization meets SOC 2 requirements.
What records explain who had production access and why?
Production-access evidence connects an identified requester and business reason to an authorization decision and the observed access period. Use the checklist below to agree a scoped evidence request with your reviewer. These are fields to verify, not a claim that OrbOps automatically collects or exports all of them.
For a sanitized example, follow a temporary read-only database request from submission through approval and withdrawal. Keep the requested end time separate from the observed end time. If the target cannot confirm withdrawal, retain an unresolved exception with an owner instead of reporting that access ended successfully.
| Record to retain | Question it answers |
|---|---|
| Requester and verified identity | Who requested access, and which identity was authenticated? |
| Business justification and request reference | Why was access needed, and which task was it tied to? |
| Target resource and permitted operations | Which environment and least-privilege scope were authorized? |
| Approver or authorizing policy and decision | Who or what authorized or denied the request, including any exception? |
| Request, decision and grant timestamps | When was access requested, approved and actually made available? |
| Approved duration and intended expiry | How long was the grant intended to last? |
| Observed expiry or revocation result | Did the target end access, including any continuing session? |
| Source references, gaps and failure owner | Where can the result be verified, and who resolves missing evidence? |
Keep the OrbOps product scope precise
The approved product scope is organizing technical control and evidence context when configured. Use the security-compliance page to discuss the current workflow and the access, lifecycle and discovery pages to identify adjacent context. Confirm actual connections and handling requirements for the private beta before providing sensitive records.
This description does not establish automated evidence collection for every system, a complete GRC platform, guaranteed audit readiness or a SOC 2 attestation for OrbOps itself. Any future customer case or product-coverage claim needs separately reviewed evidence.
Evaluate traceability and exceptions, not a compliance score
Use sanitized records for one scoped request and an independently prepared reference set. Include a missing interval, an expired access grant and a record that does not belong to the selected environment. Inspect source traceability, coverage labels, reviewer corrections and access to the resulting evidence.
Agree success criteria with the reviewer before running the pilot. Useful measures include time spent assembling the request, incorrect inclusions, missing records and review effort. None of those measures alone demonstrates control effectiveness or establishes an assurance conclusion.
Explore the relevant workflows
- Security and Compliance Agent
Review the configured evidence-context scope.
- Temporary production access
Explore approval, duration and decision records.
- Production-access approval and expiry checks
Evaluate the complete request-to-withdrawal path.
- Identity lifecycle context
Review joiner, mover and leaver workflows.
- Infrastructure context
Inspect service scope and ownership gaps.
Further reading
Bring one workflow to the beta.
Discuss your environment, required connections and approval boundaries with the OrbOps team.