Security and data
How Selo handles biometric media, how long it is kept, what leaves the service, and the status of each compliance milestone.
Last updated October 2026.
Environment
Selo runs in its own environment, with a separate cloud account, credentials and keys (KMS), a network that allows outbound traffic only to the KMS and the customer webhook, and named, minimal, audited human access. No secret is shared with the customer beyond the integration contract material: public keys and mTLS.
The metadata database holds sessions, verdicts, the audit trail and pseudonyms, never media, and it is backed up. The media store holds the encrypted images and has no backup.
Retention and destruction
| Situation | What happens to the images |
|---|---|
| Approval | Destroyed when the verdict is issued, in the same transaction. |
| Automated refusal | Kept encrypted until the review decision, within 48 hours of the case being created. |
| Hour 72 from the session opening | Destroyed, with or without a decision. |
| Expired or abandoned session | Destroyed on expiry. The user gets a free new attempt. |
| Document already linked to another account | Destroyed immediately. The case goes to review without media. |
| Scores and face models | Exist only during the analysis. |
| Audit trail | Append-only, kept for one year. |
| Operational logs | 90 days, no personal data. |
| Document pseudonym | While the linked account exists. Velocity signals, 90 days. |
Destroying means deleting the session key in the KMS, deleting the object in the store and recording the event in the audit trail. The first step is the one that guarantees the result: without the key, the object can no longer be read, even by someone with full access to the store. The store automatic expiry, at 72 hours, is a second layer.
What leaves the service
| Direction | What passes |
|---|---|
| Customer to Selo | Pseudonymous account reference, consent record, declared date of birth and document type. Name, chosen name, gender and email do not pass. |
| User to Selo | The session media, sent straight from the device with a single-use credential. It does not go through the customer API. |
| Selo to customer | The verdict (approved, refused with a technical reason, or under review) or the closure, with date, session identifier and versions. Scores, document data, images, face models and the pseudonym do not pass. |
No route, queue, export or log delivers media, and every route has a closed response schema. A contract test runs the customer parser against the real server to check that what leaves is what is documented.
Encryption and access
Media is encrypted with a key per session, protected by a master key in the KMS. The session API requires mTLS. The review console sits on a separate origin and requires a second factor. The verdict is signed with Ed25519, with a key identifier for rotation, a timestamp, a unique identifier and idempotency.
Before the analysis the image is re-encoded, and EXIF, GPS and the camera serial number are removed. The format is validated by the file bytes, not by the extension.
Gender and personal characteristics
Selo has no sex or gender field in any schema, table, event, log or message. The document reader masks the sex field when reading. Gender, appearance and name mismatch are not a reason, criterion or field for refusal. This is verified by automated tests.
Audit
The audit trail accepts additions only, with no edits or deletions, and is kept for one year. Every destruction produces an event. Reading the trail is also recorded. Logs and metrics pass through an automatic check that keeps personal data out.
Compliance
The table shows the status of each milestone in October 2026. Whatever depends on a laboratory, a contract or an external audit is marked as such, and nothing is presented as guaranteed.
| Milestone | Status |
|---|---|
| LGPD (Brazilian data protection law) | In force. Data protection impact assessment done before implementation, legal bases mapped, and a record of processing activities. |
| OWASP ASVS level 3 | The security specification of the service. Code-verifiable requirements have a test citing the requirement, and organisational ones have a justified, versioned exemption. |
| ISO/IEC 30107-3 (liveness) | Contractual requirement of the liveness engine: accredited lab test, level 1 at minimum and level 2 as the target. Not a certification of Lasso. |
| NIST FRTE | Contractual requirement of the face comparison engine: participation in the evaluation, with an accuracy and demographic differentials report. It is a published evaluation, not a certification. |
| Independent penetration test | Before go-live, yearly, and after every structural change. The report is from a third party, and findings become regression tests. |
| ISO/IEC 27001 | Programme underway: management system operating, named owner and statement of applicability. Certification by an accredited body takes 6 to 12 months after the system is operating. |
| SOC 2 Type II | Optional, if a customer requires it. Uses the same operational evidence as ISO 27001. |
How it is verified
Selo is built test first. Every business rule and requirement has an identifier, and the build fails if a rule has no test citing it. Branch coverage of the domain is 100%. A separate suite checks what matters most: that media cannot be read once the key is deleted, that approval destroys in the same transaction as the verdict, that hour 72 destroys without a decision, that the sex field does not exist, and that nothing beyond the verdict leaves the service.
The real components (database, store, cache) run the same suite as the test doubles, in temporary containers.
Reporting a vulnerability
Write to contato@lassotech.com.br with “Security” in the subject. We reply within two business days, keep you informed of progress, and give public credit if you want it. We ask for coordinated disclosure, with time to fix before publishing. There is no bounty programme yet.
Questions about this page: contato@lassotech.com.br