Data Handling

A privacy-request service is more than its own code. It depends on hosting, storage, email delivery, payment processing, security tooling, and operational infrastructure, and every provider that can touch service data extends the trust boundary of the service.

For that reason Privca treats its subprocessor relationships as a first-class disclosure and a governed lifecycle, not a static list: users and partner organizations should be able to see which categories of provider support the service, what each can and cannot access, and how those relationships are reviewed, monitored, and ended.

Most subprocessors never see readable personal data. The information a user stores with Privca is held in an encrypted vault: each record is sealed with its own data key, that key is itself encrypted by a managed key service whose keys are segregated from the application, and each data key is bound to the user it belongs to. A hosting or storage provider therefore holds ciphertext, not plaintext, and cannot read vault contents on its own.

Where a provider must handle readable data to do its job (an email gateway transmitting a request, or a payment processor handling a card), it receives only the specific data that function requires, and that access is logged. Full payment card details are handled by the payment processor and are not stored by Privca, and identifiers are minimized before reply content is passed to a provider that interprets responses. The test is the same one applied across the platform: if a provider does not need a piece of data to hold, transmit, verify, or process the user’s request, it does not receive it.

Each provider is engaged as a service provider or processor that may handle service data only on Privca’s documented instructions: to deliver the contracted function, and not for the provider’s own purposes, advertising, profiling, resale, or independent sharing. Where a provider processes personal data, Privca’s standard is to have data-processing terms in place before production use, covering confidentiality, security obligations, breach notification, limits on onward sub-processing, and deletion or return of data when the relationship ends. Operations are designed to run primarily on infrastructure in the United States; where a provider processes data elsewhere, Privca’s standard is to rely on that provider’s recognized transfer safeguards.

The lifecycle is governed end to end. Before adoption: a review of necessity, data access, security materials, incident handling, and privacy risk. A provider is adopted only when a genuine function requires it and the review is satisfactory. On an ongoing basis: re-checks that each provider remains necessary and appropriately secured, with changes reflected in the published register. At offboarding: return or deletion of service data under the terms in force and revocation of access. If a subprocessor experiences a security incident affecting Privca’s service data, it is handled within the same incident-response approach as the rest of the platform: assess the impact, take the containment steps within Privca’s control, and notify affected users and required parties in line with applicable law.

A user’s privacy rights do not stop at Privca’s own systems. When a user deletes their account or exercises a data right, Privca’s intent is to propagate that action to the providers processing their data as required: deleting or returning the relevant data and instructing providers accordingly.

Questions about how a specific provider processes your data, or about exercising a right that touches a subprocessor, can be directed to support@privca.com.

When the production provider list stabilizes, Privca will publish a named subprocessor register. For each provider it will identify the provider name, the service it performs, the categories of data it processes, the processing location where relevant, the data-processing terms in force, and whether the provider is essential to operating the platform. The register will carry its own last-reviewed date and will be updated when providers are added, removed, or materially changed.

Security reviewers, enterprise partners, and prospective customers who need the current subprocessor specifics before the public register is live may request them from support@privca.com. Requests are answered on a reasonable basis and may be subject to a confidentiality agreement until the public register is live.