Data and privacy (for DPOs)

This page is for the person who has to answer where the data lives, who can reach it, and how erasure actually works. PEART is self-hosted and offline by design, which settles several of those questions before they are asked.

Where the data lives, and what leaves

Everything PEART holds lives on the operator's own host: the SQLite database, the encrypted evidence directory, renditions and reports. The catalogs are embedded in the binary, so the tool runs in an isolated network with no external dependency at runtime. There is no telemetry and no call-home; PEART reports nothing to anyone, and can run air-gapped.

The data it holds is sensitive by nature: findings, exploitation steps, and evidence that routinely contains credentials, tokens and personal data. That is why the evidence is encrypted at the file level and the whole product is built around not leaking it.

Network addresses, and how long they stay

Two tables record a network address. Every session row carries the address the sign-in came from, and every audit entry carries the address of the request that produced it, each alongside the user agent. Both are personal data under the LGPD and the GDPR in their own right, independently of what they sit next to, and they are the one category of personal data PEART collects about the client rather than receives from the engagement.

Which address gets recorded depends on the deployment. With no trusted proxy declared, it is the address of the TCP peer, which behind a tunnel or a local terminator is the connector's own address and identifies nobody. Declaring a trusted proxy, described in Configuration, makes it the client's real address, which is the point of declaring it and also what makes the field genuinely personal data. An operator who does not want client addresses in the trail leaves the declaration unset, and the recorded value stays an infrastructure address.

Neither table is swept on a schedule. Session rows go away with the account they belong to, by cascade. Audit entries are never deleted at all, by design: the trail is insert-only, and the entry recording an engagement purge is precisely the thing meant to survive it. So an address recorded beside an engagement's activity outlives the engagement's own material, and a retention answer that speaks only of findings and evidence would be wrong about this one field.

Erasure that reaches backups

The strongest part of the privacy story is cryptographic erasure. Each engagement has its own encryption key; destroying that key renders the engagement's material illegible even in old backups the consultancy no longer controls, which no row deletion can achieve. This is the basis of the retention-purge mechanism, and it is the honest answer to "and the backups?" that a right-to-erasure request eventually asks. The purge itself is recorded in the audit trail.

What is protected, and what is declared

Evidence and backups are encrypted; the database is cleartext by a documented decision, with full-disk encryption on the host as the compensating control, and this is stated openly rather than implied. The audit trail records identifiers and never content values, so it never becomes a second, unencrypted copy of the most sensitive asset; the address and user agent it records beside them are covered above. The product does not defend against the host operator or the installation administrator, who are trusted by design with the audit trail as the only control; this too is declared, in docs/security.md section 13.

For a data protection assessment, the useful framing is that PEART gives the operator the controls (encryption, cryptographic erasure, retention purge, an insert-only audit trail, self-hosting with no external data flow) and states plainly the boundaries it does not cross, so the operator can reason about residual risk instead of trusting a vague guarantee.