Security

Compliance is not a logo wall. For Privca, it means the product, backend, support process, broker routes, and evidence records are organized around clear control expectations, and that the public claims stay inside what operating evidence supports.

The service handles sensitive privacy-request work: account access, signed authorization, locator details, broker and company submissions, target replies, documented request records, and status timelines. A credible compliance program has to explain how those pieces are governed, protected, limited, reviewed, and retained, and be honest about which claims require future third-party assessment.

Privca’s risk model is specific: authorization records, limited identity details, outbound request packages, inbound target replies, evidence records, and automated workflows that act on a user’s behalf. No single framework covers that spread well, so the architecture work follows a deliberate stack: one recognized framework per layer, chosen for fit and implemented deeply, never padded with additional frameworks for marketing breadth.

Security architecture follows NIST SP 800-207 zero-trust principles with identity-aware access in the BeyondCorp style, and machine components use a SPIFFE-model workload-identity approach. Identity assurance maps to NIST SP 800-63. Governance maps to NIST CSF 2.0 and the NIST Privacy Framework, with SOC 2 Type II as a later readiness milestone. Secure development follows the NIST SSDF (SP 800-218); application security is verified against OWASP ASVS Level 2 and the OWASP API Security Top 10; infrastructure hardening follows CIS Benchmarks and the cloud provider’s Well-Architected guidance; and operations follow NIST 800-61 incident response with autonomy governance, kill switches, and evidence chain-of-custody. The sections below walk the stack layer by layer.

The platform follows NIST SP 800-207 zero-trust principles: no request is trusted because of where it came from, every route requires an explicit policy decision, and anything unregistered is denied by default. Access to privileged surfaces is identity-aware in the BeyondCorp style rather than perimeter-based. For users, this means authorization decisions happen server-side on every request, never in the browser.

Machine identity follows the SPIFFE model on the current platform: each automated component (request workers, monitoring, inbound processing) acts under its own short-lived, least-privilege identity, so automated actions carry attributable lineage instead of sharing one all-powerful credential.

Human identity assurance maps to NIST SP 800-63: verified email at signup, hardened credential storage, optional two-factor authentication for customers, and mandatory two-factor authentication for internal roles.

Privca binds authorization to the legal name stored in the customer’s encrypted Privacy Passport and checks that match again at send time. If a target requires additional identity confirmation, the request pauses for reviewed follow-up instead of sending unsupported identity material automatically.

Governance maps to NIST CSF 2.0 and the NIST Privacy Framework together: know what data exists and why, tie every category to a product function, keep user participation visible, and treat retention as a decision rather than a default.

In practice that means a maintained inventory of every data category the service touches (account details, Privacy Passport information, authorization records, request packages, target replies, evidence artifacts, audit logs, billing state), each answering the same questions: what is the purpose, where does it live, how sensitive is it, what is the retention expectation, who can access it, and is it ever sent outside Privca. The Data Handling page publishes that mapping in user-readable form, and new data fields are not added without a purpose that survives those questions.

SOC 2 is a service-organization assurance framework, and the relevant lesson for a young platform is not to claim a report early. It is to operate like a company that can eventually be reviewed: defined controls, assigned ownership, repeatable procedures, evidence, exceptions, and management review. For Privca the most relevant trust service categories are Security, Confidentiality, and Privacy, with Availability growing in importance as users come to rely on request timelines.

The supportable claim today is readiness work: control design, evidence collection, and preparation for future formal review. A Type I report would review control design at a point in time; a Type II report requires a stable operating period with evidence that controls worked throughout it. That sequencing (evidence first, report later) is the plan.

Privca is a web application coordinating sensitive privacy workflows, so application security cannot stop at generic headers and password rules. OWASP ASVS Level 2, paired with the OWASP API Security Top 10, gives the product a systematic review bar across authentication, session handling, authorization, validation, cryptography, logging, file handling, and API behavior, applied at the actual boundaries where users, internal staff, APIs, stored records, and external providers interact.

Privca uses ASVS as its internal application-security checklist and future assessment guide. Until a formal external review is completed, this is application-security readiness, the verification bar the code is held to, rather than a third-party attestation.

Changes to the platform follow the NIST SSDF: reviewed code, dependency scanning, secret scanning, and controlled deployment with rollback paths. Guard checks in the build pipeline enforce boundaries that matter to users: for example, that authorization logic cannot drift into browser code and that evidence records stay append-only. Infrastructure configuration follows CIS Benchmarks and the cloud provider’s Well-Architected guidance: minimal public surface, private data stores, secrets in a managed parameter store, and monitored, alarmed operations.

Operational readiness follows NIST 800-61 incident response: detection, triage, containment, communication, and recorded outcomes. Because Privca automates request work, autonomy has its own governance: rate limits, circuit breakers, and kill-switch paths for every automated behavior, plus chain-of-custody logging on evidence access.

Privca’s rule for public language is that the records come first. Configuration records, audit logs, change history, policy decisions, vendor notes, incident-response paths, access reviews, retention decisions, request evidence, and security review output are what make a claim safe to publish.

That is why these pages use careful words: mapped to, designed around, readiness work, implemented control area, future assessment. Stronger words (certified, audited, formally compliant, SOC 2 Type II attested) are reserved until a third-party report or legal basis supports them.

The path is deliberately incremental: keep building reviewable operations (stable production controls, documented policies, repeatable internal reviews, vendor documentation, access-review history, incident-response exercises, security testing, and management signoff), then let third-party assessment upgrade the claims when the evidence is in place.

Nothing on this page is a certification claim, an audit report, or a guarantee; the claim-posture table above says, layer by layer, exactly what Privca asserts today. As milestones land, this page will be updated with the stronger, supported language.