LGPD

Hummand is the processor; the client is the controller. Biometric data is sensitive,
and the design answers to that: no image or template after the act.

Category
GuaranteesLGPD
HummandLGPD

The person consents per step, with versioned text; Hummand keeps hashes, not data; and what must die, dies by key destruction, on record. The data subject's rights we cannot serve yet are written here.

Processing record, retention policy and impact report exist as skeletons with markers for the data protection officer, to be closed before the first real client. The data subject's channel is dados@hummand.com.br.

Consent

Description

Two layers, in the right order: general before anything, biometric before any capture. Without the biometric one, the result is not released.

1.0General and biometricavailable

Versioned texts. Every acceptance records the timestamp, the hash of the text and the version, and the receipt carries them. General consent never unlocks biometrics.

2.0Context transparencyavailable

Before consenting, the person sees what they are authorizing: the context the client sent, in the clear only for them. The record keeps the hash and the list of keys the policy read.

3.0Mandate scopetarget architecture

When there is a mandate, acceptance of the scope is a layer of its own, distinct from the journey consent, and goes in the mandate receipt.

4.0Texts and review

The texts in use are the 2026-08 version. Review with the data protection officer is a pending decision of the plan; when it comes, it changes the version, never the history.

Minimization

Description

Only what is needed comes in, and what comes in is a hash or a ciphertext. Image and template never persist, at any moment.

1.0No image, no templateavailable

Live presence and match run, return the result, and the image and the template are discarded. Biometrics retained equals false is a product invariant, not configuration.

2.0Hashed referencesavailable

The reference the client gives the person enters as an HMAC with a per-client secret; the reference image, when there is one, as a hash; the context, as a hash plus the list of keys read.

See Receipt
3.0Minimized civil identityin accreditation

From the civil identity source only the verdict persists, encrypted; the raw response never leaves the adapter.

See Sources
4.0Envelope and isolationavailable

Data key per record, per-client isolation in the database, decryption trail with a hash chain.

See Security

Data subject's rights

Description

What we serve today, and what we do not yet: portability and erasure by CPF do not exist, and we say why.

1.0Erasure on requestavailable

By act or by the client's opaque reference: key destruction, synchronous, with the response saying how many records were affected and a record of who erased and when.

Erasure has its own scope, which no integration receives by default; in practice, the data subject asks the client, and the client erases through the dashboard.

2.0Retention by periodavailable

Encrypted verdict and CPF: 90 days. Consent evidence and event trail: five years. Automatic sweep every six hours. The policy in force is read from the service's configuration, not declared in writing: if the period changes, the response changes with it.

3.0Portability and erasure by CPFtarget architecture

They do not exist. The gateway does not store the CPF in the clear and cannot link a CPF to acts without decrypting record by record. The erasure target is the act or the reference the client itself assigned.

4.0Standalone document validationstarget architecture

Document validations made outside an act store the encrypted CPF with no link to any act; erasure on request does not reach them, and they die by the retention period. Closing that path is a recorded debt.

5.0Documents and channel

Processing record, retention policy and impact report exist as skeletons with markers for the officer, to be closed before the first real client. Hummand is the processor; the client is the controller.

Channel for data subjects and the officer: dados@hummand.com.br.

Write to dados@
1.0

Verify a receipt

Paste the JSON and the public key. No account, nothing sent: it runs in your browser.

Open the verifier
2.0

Talk to us

A technical conversation, straight with the people who build it, no sales script.

Contact