Use Cases

cPod is used across three kinds of teams: compliance managers building evidence for audits, security engineers tracking vulnerabilities and access, and IT/ops teams managing licenses and assets. Below are the most common patterns, explained at a business level alongside the technical integration.

1. SOC 2 Evidence Collection

The problem: Your auditor wants evidence that access is reviewed, controls are assessed, and changes are logged. This evidence lives in five different tools — your IdP, your ticketing system, your cloud console, your HRMS, and a spreadsheet.

How cPod helps: cPod stores ComplianceControl records (one per SOC 2 criterion), links each control to its owner (Person), tracks assessment status (compliant / non_compliant / in_review), and auto-logs every change with a tamper-evident audit event. Auditors get a single API endpoint that returns everything they need — timestamped, hash-chained, and exportable.

What the compliance manager sees:

• A list of all SOC 2 controls with current status and owner
• A history of every status change, who made it, and when
• Evidence that changes cannot be retroactively altered (hash-chained log)

Example — list all non-compliant SOC 2 controls:

const controls = await sdk.risk.controls.list({
  framework: 'SOC2',
  status: 'non_compliant',
})
// Returns: controlId, title, owner, lastAssessedAt, description

Example — pull the audit trail for a specific control:

const auditEvents = await sdk.telemetry.audit.query({
  resourceType: 'compliance_control',
  resourceId: 'ctrl-CC6.1',
  from: '2026-01-01T00:00:00Z',
})
// Every update, who made it, before/after snapshot

2. User Access Reviews (Quarterly or Continuous)

The problem: Access reviews for SOC 2 CC6.3 require proving that every person’s access is appropriate and that leavers are deprovisioned. This normally means exporting spreadsheets from Okta, AWS IAM, and GitHub, then manually reconciling them.

How cPod helps: cPod’s Person, AccessEntitlement, and Relationship domains create a live graph of who has access to what. When someone leaves the company, their Person record is soft-deleted — the entitlement remains for audit purposes but the status change is logged. Quarterly access reviews become a query, not a spreadsheet merge.

What the compliance manager sees:

• All active employees and their entitlements in one view
• Employees who left but whose access was not revoked within SLA
• A timestamp of every access grant and revocation

Example — find all active entitlements for people who are no longer active:

// Get inactive people
const leavers = await sdk.people.list({ status: 'inactive', type: 'employee' })
 
// For each leaver, check their remaining entitlements
for (const person of leavers.items) {
  const entitlements = await sdk.relationships.list({
    fromId: person.id,
    type: 'has_access_to',
  })
  if (entitlements.items.length > 0) {
    // Flag for access revocation follow-up
    console.log(`${person.firstName} ${person.lastName} still has ${entitlements.items.length} entitlement(s)`)
  }
}

3. Software License Compliance

The problem: You have 200 SaaS subscriptions. Finance doesn’t know which ones are used; IT doesn’t know which ones are over-licensed. At audit time, nobody can prove that software licenses match headcount.

How cPod helps: The SoftwareLicense and LicenseAssignment domains track every license and who it is assigned to. Relationships link LicenseAssignment to Person, so you can instantly answer: how many seats are we paying for vs. how many are assigned?

What the compliance manager sees:

• Every software license with seat count, vendor, and renewal date
• Which employees hold which license assignments
• Unassigned seats (waste) and over-assigned products (compliance risk)

4. Vulnerability Remediation Workflow (Security Engineers)

The problem: Your scanner (Tenable, Wiz, Qualys) surfaces critical CVEs, but remediation tracking is manual — Jira tickets, Slack messages, spreadsheets. When the auditor asks “which critical vulnerabilities were open last quarter and who was responsible?”, nobody has a clean answer.

How cPod helps: cPod’s Vulnerability entity stores CVE details, severity, CVSS score, affected asset, assignee, and due date. Vulnerabilities link to CloudResource or PhysicalAsset entities via the graph. Track status (open → in_progress → resolved) as remediation proceeds — every status change is automatically audit-logged.

What the security engineer can do in 15 minutes:

• List all open critical vulnerabilities with owner and remediation deadline
• Bulk-assign vulnerabilities to the responsible engineer
• Report on overdue vulns by team / department

import asyncio
from datetime import datetime, timezone
from cpod import AsyncCpodClient
from cpod.models import Severity, VulnerabilityStatus
 
async def triage_critical_vulns():
    async with AsyncCpodClient.from_env() as sdk:
        # List all open critical vulnerabilities
        vulns = await sdk.risk.list_vulnerabilities(
            severity=Severity.CRITICAL,
            status=VulnerabilityStatus.OPEN,
            limit=100,
        )
        print(f"Found {len(vulns.data)} open critical vulnerabilities")
 
        now = datetime.now(timezone.utc)
        for v in vulns.data:
            overdue = v.due_at and v.due_at < now
            flag = " [OVERDUE]" if overdue else ""
            print(f"  [{v.cve}] {v.title} — CVSS {v.score}{flag}")
            print(f"    Assignee: {v.assignee_id} | Due: {v.due_at}")
 
            # Mark as in-progress with a note
            await sdk.risk.update_vulnerability_status(
                v.id,
                status=VulnerabilityStatus.REMEDIATED,
                notes="Triaged and assigned for patch cycle",
            )
 
asyncio.run(triage_critical_vulns())

import { CpodClient } from '@cpod/sdk'
 
const sdk = CpodClient.fromEnv()
 
// List all open critical vulnerabilities
const vulns = await sdk.risk.vulnerabilities.list({
  severity: 'critical',
  status: 'open',
  limit: 100,
})
console.log(`Found ${vulns.items.length} open critical vulnerabilities`)
 
const now = new Date().toISOString()
for (const v of vulns.items) {
  const overdue = v.due_at && v.due_at < now
  console.log(`  [${v.cve}] ${v.title} — CVSS ${v.score}${overdue ? ' [OVERDUE]' : ''}`)
 
  // Update status to in_progress
  await sdk.risk.vulnerabilities.update(v.id, { status: 'in_progress' })
}

5. Explaining cPod to Your CTO

If you are a compliance manager preparing a briefing, here is what to tell your engineering leader:

What cPod is: An enterprise data platform with a typed, graph-connected schema that spans people, technology assets, software licenses, cloud resources, and risk. Every entity is linked to every other entity through relationship edges. The whole thing is audited automatically.

Why we need it: Today our compliance evidence is scattered across Okta, AWS, JIRA, Tenable, and spreadsheets. Pulling audit evidence for SOC 2 takes two engineers two weeks. With cPod, our engineers integrate once and compliance teams query evidence in real time.

How it compares:

• vs. ServiceNow: cPod is developer-first with typed SDKs and an open data model. No low-code forms, no $400k implementation engagement.
• vs. Axonius: cPod is a read/write platform, not just an asset inventory. You can push data in, track remediation, and build workflows on top of it.
• vs. Spreadsheets: cPod has a tamper-evident audit log. Evidence cannot be retroactively altered.

What our engineers do: Install the SDK (npm install @cpod/sdk), configure two environment variables (CPOD_API_URL, CPOD_API_KEY), and start pushing data. Every write is automatically logged. Everything is queryable by the compliance team from day one.

Next Steps