Trust
SOC 2 Alignment How Avnology ID aligns with SOC 2 Trust Service Criteria.
Avnology ID is designed to align with SOC 2 Type II Trust Service Criteria. This page provides a detailed mapping of each criterion to the controls implemented in Avnology ID, along with guidance on gathering audit evidence.
SOC 2 evaluates five Trust Service Criteria (TSC). Avnology ID addresses all five:
Criterion Coverage Key controls Security (CC)Full Authentication, authorization, encryption, audit logging, vulnerability management Availability (A)Full 99.99% SLA, multi-AZ, automated failover, monitoring Confidentiality (C)Full Encryption at rest/transit, network isolation, access controls Processing integrity (PI)Full Input validation, token verification, CSRF protection Privacy (P)Full Data minimization, consent, deletion, export
Control Implementation Evidence CC1.1 Integrity and ethical values Security policy, responsible disclosure program Policy documents, security.txt CC1.2 Board oversight Security review in every release cycle Release checklists, security review logs CC1.3 Organizational structure Separation of duties between dev, ops, and security teams Role definitions, access control lists CC1.4 Competence Security training requirements for all engineers Training records
Control Implementation Evidence CC2.1 Internal communication Security advisories, incident runbooks Internal documentation, runbook audit trail CC2.2 External communication Status page, changelog, vulnerability disclosure policy status.avnology.com , security.txt
Control Implementation Evidence CC3.1 Risk identification Threat modeling, annual penetration testing Threat model documents, pentest reports CC3.2 Risk analysis Built-in risk engine scores every sign-in attempt Risk assessment logs, conditional access policies CC3.3 Fraud risk Breached password detection, impossible travel detection HIBP integration logs, risk engine audit trail CC3.4 Change-related risk Breaking change detection in CI, canary deployments CI/CD pipeline logs, deployment records
Control Implementation Evidence CC4.1 Ongoing monitoring Prometheus metrics, Grafana dashboards, automated alerting Dashboard configurations, alert rules, incident history CC4.2 Internal control deficiency remediation Security findings tracked as issues, SLA for remediation Issue tracker, SLA compliance reports
Control Implementation Evidence CC5.1 Selection of controls Defense-in-depth: network, application, identity layers Architecture documentation CC5.2 Technology controls Automated CI/CD, container scanning, SBOM generation Pipeline logs, scan reports, SBOM artifacts CC5.3 Control deployment Infrastructure as code, immutable deployments Terraform state, Helm release history
Control Implementation Evidence CC6.1 Logical access security ReBAC (relationship-based access control), principle of least privilege Permission model, relation tuples CC6.2 User registration and authorization MFA enrollment, passkeys, admin role management User records, MFA enrollment logs CC6.3 User deprovisioning SCIM deactivation, admin-initiated deletion, GDPR cascade Deletion logs, SCIM sync records CC6.6 Threat protection Rate limiting, CAPTCHA, risk engine, account lockout Rate limit configuration, risk assessment logs CC6.7 Restriction on software Container image signing, admission controller verification Cosign signatures, admission controller logs CC6.8 Vulnerability detection Dependency scanning, container scanning, pentest Scan reports, CVE remediation records
Control Implementation Evidence CC7.1 Infrastructure monitoring OpenTelemetry traces, Prometheus metrics, Loki logs Grafana dashboards, alert history CC7.2 Anomaly detection Risk engine, login failure spike alerts, token endpoint error alerts Alert rules, incident records CC7.3 Incident response Documented runbooks, on-call rotation, post-incident reviews Runbook documents, PIR records CC7.4 Incident recovery Automated failover, database point-in-time recovery Recovery test records, RTO/RPO measurements
Control Implementation Evidence CC8.1 Change authorization Pull request reviews, CI checks, buf breaking change detection PR history, CI logs CC8.2 Testing Automated unit, integration, E2E tests; testcontainers for real DB Test reports, coverage metrics CC8.3 Deployment controls Canary deployments, rollback automation, feature flags Deployment logs, rollback records
Control Implementation Evidence CC9.1 Risk mitigation Conditional access policies, per-org security settings Policy configurations, enforcement logs CC9.2 Vendor management Dependency scanning, SBOM, license compliance SBOM artifacts, license audit reports
Control Implementation Evidence A1.1 Processing capacity Horizontal pod autoscaling, database read replicas HPA configurations, scaling event logs A1.2 Environmental protections Multi-AZ deployment, geographic redundancy Infrastructure topology, AZ distribution A1.3 Recovery procedures Automated database backup, point-in-time recovery, documented DR plan Backup schedules, recovery test records
Metric Target Measurement Overall availability 99.99% < 52 minutes downtime per year RTO (Recovery Time Objective) < 15 minutes Time to restore service after failure RPO (Recovery Point Objective) < 5 minutes Maximum data loss window Backup frequency Continuous (WAL streaming) + daily full PostgreSQL WAL archiving Backup retention 30 days Point-in-time recovery window
Control Implementation Evidence C1.1 Confidential information identification Data classification: credentials (critical), PII (sensitive), metadata (internal) Data classification policy C1.2 Confidential information disposal 14-point GDPR cascade deletion, cryptographic erasure Deletion audit logs
Category Examples Encryption Access Critical Password hashes, OAuth client secrets, API key hashes, SAML certificates AES-256-GCM (application layer) + AES-256 (database layer) Service accounts only, no human access Sensitive Email, phone, name, profile data AES-256 (database layer) Admin API with audit logging Internal Organization names, OAuth client names, webhook URLs AES-256 (database layer) Admin API Public Organization slugs, JWKS, discovery endpoints None required Public access
Control Implementation Evidence PI1.1 Quality of processing Server-side protobuf validation (protovalidate), Zod schema validation on frontend Validation rules in .proto files PI1.2 Accuracy of outputs JWT signature verification against JWKS, SAML assertion signature validation Token verification logs PI1.3 Completeness of processing Webhook delivery with retry, DLQ for failed deliveries, idempotency keys Delivery logs, DLQ records PI1.4 Timeliness of processing SLA targets (p99 < 300ms login, p99 < 50ms permission check) Latency metrics, SLA reports
Control Implementation Evidence P1.1 Privacy notice OAuth consent screen with granular scope selection Consent records P2.1 Data collection limitation Configurable identity schemas -- collect only needed fields Schema configurations P3.1 Data retention Configurable audit log retention, session TTL, token TTL Retention policies P4.1 Data use limitation Scope-based access control, purpose limitation in consent Scope definitions, consent records P5.1 Data quality Email/phone verification flows Verification records P6.1 Data access (DSAR) JSON export of all user data via admin API Export logs P6.5 Data deletion GDPR Art. 17 cascade deletion (14-point cleanup) Deletion audit trail P7.1 Third-party data handling Webhook payload filtering, no sensitive data in logs Webhook configurations, logging policy P8.1 Data breach notification Incident response procedure, 72-hour GDPR notification timeline Incident response plan
Avnology ID maintains immutable, append-only audit logs for all security-relevant events. Export these logs for your compliance team or SIEM:
const events = await auth.admin.listAuditEvents({
since: "2026-01-01T00:00:00Z",
until: "2026-03-31T23:59:59Z",
eventTypes: ["auth.login.*", "user.*", "organization.*"],
pageSize: 1000,
curl "https://api-id.avnology.net/v1/audit/events?since=2026-01-01T00:00:00Z&until=2026-03-31T23:59:59Z&page_size=1000" \
-H "Authorization: Bearer ADMIN_API_KEY"const events = await auth.admin.listAuditEvents({
since: "2026-01-01T00:00:00Z",
until: "2026-03-31T23:59:59Z",
eventTypes: ["auth.login.*", "user.*", "organization.*"],
pageSize: 1000,
curl "https://api-id.avnology.net/v1/audit/events?since=2026-01-01T00:00:00Z&until=2026-03-31T23:59:59Z&page_size=1000" \
-H "Authorization: Bearer ADMIN_API_KEY"
Avnology ID supports real-time log streaming to popular SIEM platforms:
SIEM Integration method Splunk Webhook to Splunk HEC endpoint Datadog Webhook to Datadog HTTP intake Elastic / ELK Webhook to Elasticsearch ingest endpoint Microsoft Sentinel Webhook to Sentinel data connector Google Chronicle Webhook to Chronicle ingestion API
Configure a webhook with the audit.* event category to stream all audit events to your SIEM in real time.
Avnology ID runs continuous compliance checks:
Check Frequency What it verifies MFA adoption rate Daily Percentage of users with MFA enrolled Dormant accounts Weekly Accounts inactive > 90 days Unused service accounts Weekly Service accounts with no API calls > 90 days Password age Daily Users with passwords older than the org policy Admin role review Monthly Users with admin roles, flagged for review Failed login trends Real-time Spike detection for potential attacks
Query compliance metrics via the analytics API:
const metrics = await auth.admin.getComplianceMetrics({
organizationId: "org_acme",
});
console.log(metrics.mfaAdoptionRate); // 0.87 (87%)
console.log(metrics.passkeyAdoptionRate); // 0.42 (42%)
console.log(metrics.dormantAccountCount);
If your organization is undergoing a SOC 2 audit, Avnology ID provides the following to support evidence gathering:
Audit log exports -- Full event history in JSON or CSV format
Configuration snapshots -- Current security settings, policies, and role assignments
SIEM integration -- Real-time event streaming for continuous monitoring evidence
Compliance metrics API -- Programmatic access to adoption and security metrics
Pentest reports -- Available to enterprise customers under NDA
SBOM -- Software Bill of Materials for supply chain verification