Requests & Evidence

Many U.S. state privacy laws, California’s CCPA/CPRA among them, let a consumer authorize another party to exercise privacy rights on their behalf. That party is an “authorized agent.” The laws generally expect the receiving business to confirm the agent has permission, to verify the consumer’s identity, and in some cases to obtain written authorization or additional proof before acting, particularly for deletion.

Privca operates inside that framework. It does not create a right that does not already exist; it exercises the rights a user already holds, in a form a receiving company can recognize and act on.

For a company to act on an agent request without guesswork, three things have to be clear: that a specific person is exercising a specific right, that they genuinely gave the agent permission, and that the request can be tied to the correct record. Ambiguity on any one of these is what turns a valid request into a support loop or a refusal.

So before any request is prepared, the user grants authorization inside Privca: a typed-name electronic signature, an authorized-agent consent record, and acknowledgement of the interstate-disclosure and scope terms that apply, timestamped and tied to the specific request purpose. Authorization is not a one-time, permanent grant: it carries a freshness window and must be re-affirmed once it lapses, so a request is never sent on the strength of stale, long-forgotten permission.

A signature only means something if it belongs to the person it names. Privca checks the typed signature against the legal name in the user’s encrypted Privacy Passport before a package can be prepared, and re-checks it at send time: a mismatch stops the request instead of sending it. This is what prevents someone from authorizing action under a name that is not theirs.

If a target asks for direct identity confirmation or additional proof, Privca records the challenge and moves the request to reviewed follow-up. It does not automatically send government identification or other unsupported identity material.

Where a route needs it, Privca generates a signed authorization document connecting the user, the request purpose, the target context, and the date of authorization, and attaches it to the request. The company receives evidence of authority in a consistent form rather than a claim buried in an email body. That artifact, and the fact of its delivery, are recorded as part of the request’s evidence trail.

Alongside it travel practical matching details: name, contact, state, and, depending on the route, address, account context, or other hints. Privca sends only what a given target’s route actually needs to make the match, keeps high-risk identifiers out of ordinary automated flows, and states the action plainly (opt out, delete, or both where supported) so there is no ambiguity about what is being asked.

What a target receives is a controlled artifact. The compliant-request language is versioned and reviewed, and no component rewrites it at send time. Every send records the user it was for, the template version, the policy version, and the automated identity that produced it.

That discipline is what makes a Privca request straightforward for a privacy team to evaluate: a clear requester, a clear right, authorization where needed, minimal relevant data, and language that does not shift from one request to the next.

A company may still verify identity, decline an authorization format, point to a portal, rely on a statutory exception, or require the user to complete a step directly. These are legitimate parts of the process, and Privca treats them as outcomes to record rather than silent failures: the reply is captured, the required action is marked, and the user is told plainly what to do next.

Sensitive verification challenges are reviewed before any additional evidence is produced. Escalating to share more is a deliberate decision, never an automatic reply.

Evidence capture turns privacy work into a trackable workflow: a user can know a request was prepared, submitted, received or answered, and moved through a defined lifecycle. And when a target asks for more, fails to respond, rejects a request, or claims completion, the follow-up cites the record, not a recollection.

Privca may record the selected target, request goal, route type, readiness checks, generated request package metadata, outbound send events, broker or company replies, action-required notices, review decisions, escalation attempts, completion records, failure reasons, cancellation records, and timestamps. The record focuses on operational context and avoids unnecessary duplication of sensitive user details.

Evidence records are write-once: once captured, they are not edited or silently deleted by any workflow. Reads of sensitive evidence are custody-logged, so access to the record is itself part of the record. That integrity is enforced in the platform’s data layer: a structural property, not a policy promise.

Records are kept for as long as they serve accountability and no longer than a defined retention schedule allows; removal follows a governed retention workflow, not an ad-hoc purge. Because the record is write-once, retention is only ever about when a whole record ages out, never about quietly changing what a record says while it exists.

The dashboard translates evidence into four plain states: queued, sent, done, and closed, each with a short line saying why. A request that needs user action explains the action instead of hiding it behind a generic status, and if a target already has an active request or history, Privca guides the user to the existing record instead of creating duplicate work.

Evidence is useful only if it is controlled: request records are protected by account access, internal role limits, custody-logged reads, retention rules, and careful display decisions. Privca preserves what accountability needs, without turning the evidence store into a second copy of everything sensitive.

The authorized-agent process removes avoidable failure modes (unclear authority, missing context, oversharing, unverifiable history), but it does not override a target’s lawful verification requirements, statutory exceptions, or jurisdictional limits, and it cannot guarantee a particular outcome.

Privca acts as an authorized privacy agent, not a law firm. It prepares, submits, monitors, and documents supported requests; it does not provide legal advice or control how a company ultimately responds.