Data Handling

Engagement & Data Handling

For a penetration testing firm, the most important security question is simple: what happens to my data during an engagement? This page answers it in full.

Last updated: August 2026

Per-engagement isolation

Each client's engagement data is segregated. One engagement can never touch another's data.

Same rigor for ourselves

We secure our own environment and the KLUE platform with the same rigor we apply when testing our clients' systems.

NDA-first

A mutual NDA is signed before any sensitive data is exchanged. Engagement-specific scoping is always documented.

What client data we handle

During a security engagement, Shellvoide may receive or generate:

Target scope and credentials you provide for testing
Source code, where you grant access for code review
Cloud and Microsoft 365 configurations under audit
Findings, exploit artifacts, screenshots, and attack-path evidence generated during testing
Communications and scoping notes

How your data is handled across the engagement

Engagement kickoff & scoping

Every engagement starts with a signed scope of work and an NDA before any client data is exchanged.
Scoping defines the targets, access level (no-knowledge, partial, or full access), and the data we will receive or collect.
A named, certified tester is assigned as the single point of contact and data custodian for the engagement.

During the engagement

Client data, including target credentials, source code, configurations, findings, and exploit artifacts, is stored in an isolated workspace restricted to the named testers on the engagement.
Engagement data is encrypted in transit (TLS 1.2+) and at rest (AES-256).
Hands-on engagements run in isolated, ephemeral environments that are destroyed when the engagement completes, along with any working copies of client material.
Outbound connections from engagement environments are allow-listed; credentials used to clone source are short-lived and scrubbed after use.
No client engagement data is used to train our models or shared across engagements.

Access

Only the named testers assigned to an engagement can access that engagement's data. There is no broad internal access to client findings.
All access is authenticated, logged, and attributable to an individual.
Access is revoked when an engagement closes or a tester rolls off.

Retention

Engagement artifacts (reports, findings, exploit proofs) are retained in the client workspace until the client deletes them or the retention period ends.
Sandbox and ephemeral compute environments are destroyed on completion; working copies of client code and configuration do not persist.
Residual copies may exist only in encrypted backups for a limited window before being overwritten.
Clients can request early deletion of their engagement data at any time.

Destruction

On retention expiry or client request, engagement data is deleted from primary storage and the client workspace.
Ephemeral environments are torn down and their working state is not retained.
Destruction is verified against the retention schedule as part of our ISMS controls.

Government & regulated clients

We work with public-sector and regulated clients and can accommodate additional handling requirements, including data residency constraints, on-premise or self-managed model deployments for sensitive workloads, and custom contractual terms.

For KLUE specifically, the platform is model-agnostic: for sensitive workloads, locally hosted or self-managed model deployments can be arranged so that data does not leave a controlled environment.