Why human attestation
Shield does not run automated identity verification. The document upload is a hand-off mechanism: the requester sends you proof, you look at it, and you record that you looked. The audit entry records your name, your timestamp, and (if you ever revoke) the prior verifier and reason. That trail is the evidence a regulator asks for when they ask "how did you confirm this was the data subject?"
Automated verification is a Tier 2 add-on. Tier 1 Shield expects you to actually open the document and look at it. The attestation modal is your commitment.
Open the request
Open the Detail page for any request that has an Identity Doc row. If the requester did not upload anything, this whole workflow does not apply and the Verification row does not render. When a doc is attached, the Verification row sits directly below the Download Document link and shows the current state.
Download the identity document
Click Download Document. The link generates a 5-minute presigned S3 URL and writes identity_doc.downloaded to the audit trail. The file is private to your S3 bucket and never publicly reachable; even if someone has the URL, it expires in 5 minutes.
Review the document
Open the downloaded file and confirm:
- The name on the document matches the requester's submitted name.
- The photo (if present) is clear and identifiable.
- The document is government-issued (passport, driver's license, national ID) and unexpired.
- There's no obvious tampering, watermarking inconsistency, or PDF metadata that screams generated.
If anything looks off, do not verify. Reject with a written reason and ask for a clearer or alternative document.
Mark verified
Click Mark Verified. The attestation modal explains that this action records your name and timestamp into the audit. Confirm only after you actually reviewed the document. The audit writes identity.verified with your user id, your name, the timestamp, and a flag noting a document was on file.
Clicking Mark Verified without actually reviewing the document creates false compliance evidence. The audit trail attributes the verification to your name. If a regulator later challenges the decision, the audit entry is what you'll be defending in front of legal.
Revoke if needed
If on second review the document is insufficient (blurry photo, expired ID, name mismatch you missed the first time), click Revoke on the green Verified pill. A modal appears asking for a reason. Enter what you found and confirm. The audit writes identity.unverified with your reason, plus the prior verifier's name and timestamp, so the full review history is preserved.
Revoke does not delete the prior verification entry. Both identity.verified and identity.unverified stay in the trail. A regulator can see the full timeline: who verified, when, who revoked, when, why.
Verify under your own user account, not a shared admin login. The audit trail attributes verification to whoever is logged in. If multiple people on your privacy team handle requests, the audit needs to point to a real human, not "admin".
Troubleshooting
Verification row does not appear
The requester did not upload an identity document. Without a doc, there's nothing to verify. If the request requires verification under your policy, ask the requester to resubmit with a document, or use the Reject workflow with a reason explaining the missing verification step.
Document download returns 403 or 404
The presigned URL expired (5 minutes from generation) or the S3 lifecycle deleted the file. If the request is older than 365 days, the S3 lifecycle on uploads/request/ will have hard-deleted the file as a safety net. The Detail page reflects this; the Download Document link will fail. If the request is recent and the URL just expired, click Download again to generate a fresh one.
I verified the wrong request
Click Revoke on the Verified pill with a reason explaining the mistake. Then verify the correct request. Both audit entries are preserved, which is the right outcome for compliance.