Peveka.
Security

CERTIFICATIONS
& STANDARDS

The compliance frameworks, certifications, and standards that govern how Peveka handles client data — verified by independent third parties, not self-attested.

01

FedRAMP-Compatible Architecture / IL4-Deployable Design

Federal deployment posture without overclaim.

Peveka is engineered against the FedRAMP Moderate baseline and built to deploy within client-authorized federal cloud enclaves. For federal programs requiring FedRAMP or DOD IL4 compliance, Peveka deploys within the client's own authorized government cloud boundary — inference routes through FedRAMP-authorized backends (Vertex AI on GCP Government, us-gov-central1; or AWS GovCloud Bedrock, us-gov-west-1). The authorization belongs to the host enclave; Peveka inherits the boundary.

Federal Cloud Inference Backends

The default inference backend for federal Peveka deployments is Vertex AI on Google Cloud Platform Government (us-gov-central1) — a FedRAMP High authorized region physically located within the continental United States. All data processed by the inference layer — query text, uploaded files, knowledge base content — remains within the host backend's authorization boundary at all times. Peveka does not process or retain data outside that boundary.

  • ✓Vertex AI — GCP Government, us-gov-central1 (FedRAMP High authorized backend)
  • ✓All data remains within the host backend's authorization boundary
  • ✓AWS GovCloud Bedrock (us-gov-west-1) as alternate backend
  • ✓CONUS-only data residency for all federal deployments

IL4 Enclave Deployment Pattern

For programs with DOD IL4 requirements, Peveka is designed to deploy within the client's own DOD IL4-authorized enclave. The full forensic engine — including the knowledge base, format parsers, and inference routing layer — runs within the enclave boundary. No external network calls are required for any forensic function after initial deployment configuration. The IL4 authorization sits with the host enclave; Peveka is the workload that runs inside it.

  • ✓Full engine deployable within client DOD IL4-authorized enclave boundary
  • ✓No external network calls required for forensic functions
  • ✓Knowledge base and parsers co-located within enclave
  • ✓Deployment configuration reviewed by client security team
02

Enterprise Authentication

Zero-trust identity enforcement.

Auth0 Enterprise identity platform with RS256 JWT token signing. Multi-factor authentication is mandatory for all users — there is no bypass path. SAML 2.0 SSO with Okta, Azure Active Directory, and Google Workspace. SCIM 2.0 automated user provisioning. Role-based access control with Admin, Analyst, and Viewer roles assignable per workspace.

Identity & Token Architecture

Peveka uses Auth0 Enterprise as its identity platform. All session tokens are signed using RS256 asymmetric key pairs — the signing key is never exposed to the application layer. Tokens have a maximum lifetime of one hour, after which re-authentication is required. MFA is enforced at the Auth0 level, not the application level — there is no application code path that can bypass the MFA requirement.

  • ✓Auth0 Enterprise identity platform
  • ✓RS256 JWT with asymmetric key signing
  • ✓Maximum token lifetime: 1 hour
  • ✓MFA enforced at identity provider level — not bypassable at application layer

SSO, SCIM & RBAC

SAML 2.0 SSO integrations are available with Okta, Azure Active Directory, and Google Workspace. SCIM 2.0 provisioning enables automated user lifecycle management — users added to your identity provider directory are automatically provisioned in Peveka, and users removed from your directory are automatically deprovisioned. Role assignments (Admin, Analyst, Viewer) are managed per workspace and per user.

  • ✓SAML 2.0 SSO: Okta, Azure AD, Google Workspace
  • ✓SCIM 2.0 automated provisioning and deprovisioning
  • ✓Admin, Analyst, and Viewer roles per workspace
  • ✓Role assignments audited and exportable
03

GDPR / CCPA Compliance

Data subject rights, fully implemented.

GDPR Article 17 right of erasure and CCPA right to deletion are enforced at the infrastructure level — not as a manual process. Data residency is maintained in US regions for all non-federal deployments. Data subject access requests are processed within the regulatory timeframes.

Right of Erasure at Infrastructure Level

When a data subject requests erasure under GDPR Article 17 or CCPA, the deletion is executed at the infrastructure level — not as a soft delete or a flag in a database. Tenant deletion cascades to all associated files, knowledge base entries, audit logs (subject to legal retention obligations), and session history. The stateless architecture means that session-scoped data is already erased on session close — erasure requests apply to any data that has been explicitly retained.

  • ✓GDPR Article 17 and CCPA right to deletion enforced at infrastructure layer
  • ✓Tenant deletion cascades to all associated data
  • ✓Stateless architecture ensures session data is already erased on close
  • ✓Erasure completion documented and confirmable

Data Residency & Processing Records

All data processed by Peveka for non-federal deployments is maintained in US regions. The platform maintains records of processing activities (RoPA) as required by GDPR Article 30. Data subject access requests (DSARs) are processed within the 30-day GDPR and 45-day CCPA response windows. A Data Processing Agreement (DPA) is available for all enterprise clients.

  • ✓US region data residency for all non-federal deployments
  • ✓Records of processing activities (RoPA) maintained per GDPR Article 30
  • ✓DSAR processing within GDPR 30-day and CCPA 45-day windows
  • ✓Data Processing Agreement (DPA) available for enterprise clients
04

EVMS Audit Trail

Native compliance logging for federal programs.

All forensic audit runs and system actions are logged to a tamper-evident, append-only audit store with a minimum one-year retention. Exportable as JSON or CSV for DCMA surveillance documentation, DOE EVMS compliance records, and internal control evidence. Every forensic audit run is logged with the schedule data analyzed, metrics evaluated, findings generated, and the analyst who initiated the run.

Tamper-Evident Log Architecture

The audit log uses an append-only architecture with cryptographic hash chaining. Each log entry contains a timestamp, the authenticated user, the action type, the affected resource identifiers, and a cryptographic hash that links it to the preceding entry. Log entries cannot be modified or deleted — only appended. Any modification to a historical entry breaks the hash chain and is immediately detectable.

  • ✓Append-only log — entries cannot be modified or deleted
  • ✓Cryptographic hash chain linking each entry to the preceding
  • ✓Tamper-evidence holds for all users including administrators
  • ✓Hash chain break immediately detectable

Retention, Export & Federal Compliance

Audit logs are retained for a minimum of one year. Logs are exportable as JSON or CSV, scoped to the requesting tenant. Every forensic audit run is logged with complete provenance: the schedule file analyzed, the metrics evaluated, the findings generated, the corrective actions recommended, and the analyst who initiated the run. This record satisfies the DCMA surveillance evidence requirements and DOE EVMS documentation obligations.

  • ✓Minimum one-year retention per log entry
  • ✓Exportable as JSON or CSV, scoped to tenant
  • ✓Full provenance per forensic run: file, metrics, findings, analyst
  • ✓Satisfies DCMA surveillance and DOE EVMS documentation requirements