Data Retention & Redaction Policy

1. Plain-English Summary

We retain only what we need to operate the platform, deliver services, support customer packets, meet legal and security obligations, and preserve the evidence required for agreed work. We redact or delete sensitive material when it is no longer needed, subject to the applicable SOW, DPA, ROE, Evidence Handling Policy, legal obligations, and customer instructions.

In practice:

• public forms should not receive secrets, production credentials, access keys, regulated data, or sensitive customer records;
• retention depends on the type of data, workspace settings, engagement scope, agreement path, and legal or security obligations;
• raw evidence should be minimized, redacted, or deleted where practical;
• final reports, legal records, billing records, and audit or security records may be retained longer; and
• customers can request deletion or export subject to legal, billing, security, backup, and contractual limits.

2. What This Policy Covers

This policy covers the records we may create or store across the public website, trust center, customer portal, and product workflows, including:

• website and contact submissions;
• anonymous scope sessions;
• authenticated /scope and /start intake records;
• generated readiness packets;
• Workbench Copilot prompts and outputs;
• uploaded artifacts and files;
• screenshots, logs, traces, and request or response samples;
• target and system metadata, including cloud or AWS metadata;
• pentest and red-team evidence;
• reports and deliverables;
• NDA, SOW, DPA, ROE, and private-offer records;
• Stripe, billing, and subscription records;
• LMS and training records;
• security and audit logs;
• integration metadata; and
• support communications.

3. Retention Categories

Public website and contact data

Retained as needed to answer the request, prevent abuse, preserve operational records, and satisfy legal obligations. Public forms are for preliminary, non-sensitive information only.

Scoping and intake records

Retained as needed to prepare packets, route the engagement, document authorization boundaries, and preserve the scoping history.

Customer workspace and platform records

Retained as needed to operate the platform, support admin actions, preserve the engagement record, and maintain workspace history.

Generated packets and draft deliverables

Retained as needed to support delivery, review, customer approvals, and claim-readiness review. Drafts may remain linked to the workspace or engagement record until they are replaced, deleted, or archived under the applicable agreement.

Security evidence and uploaded artifacts

Retained as needed to support authorized reviews, validate findings, prepare deliverables, and meet evidence handling or retention obligations. Raw evidence is minimized when a redacted or derived form is sufficient.

Workbench Copilot and chat records

Retained as needed to support the workspace, packet, project, audit trail, customer support, and the specific feature request. These records may be retained with the relevant workspace or engagement record when the feature is enabled.

Contract and procurement records

Retained as needed to prepare, approve, administer, and evidence the engagement.

Billing and subscription records

Retained as needed for payment processing, accounting, refunds, disputes, renewals, taxes, and legal compliance.

LMS and training records

Retained as needed to deliver training, manage licenses, and support customer reporting.

Integration metadata

Retained as needed to support connected services, troubleshoot issues, review permissions, and manage revocation.

Security logs and audit events

Retained as needed to secure the platform, investigate incidents, support reviews, and meet legal or contractual obligations.

Support communications

Retained as needed to resolve the issue, preserve the support history, and support security or legal review where needed.

Deleted or deactivated workspace data

When a workspace is deleted or deactivated, some records may remain in backups, audit trails, billing records, or legal and security archives for a limited period. Where supported, active workspace access is removed first, and deletion is then carried out according to the relevant system and agreement path.

4. Redaction Defaults

By default, redact or mask:

• passwords;
• API keys;
• OAuth tokens;
• access tokens;
• session cookies;
• private keys;
• production credentials;
• customer personal data;
• payment data;
• health data;
• secrets in logs;
• unrelated third-party data;
• unnecessary employee or customer identifiers;
• exploit details not needed for remediation;
• screenshots containing unrelated records;
• internal infrastructure identifiers where not needed; and
• prompt or log fragments that include secrets or unrelated personal data.

The goal is to preserve enough context to support the work while removing material that is not needed for the scoped purpose.

5. What We Try Not to Retain

We prefer:

• summaries before raw dumps;
• redacted logs before full logs;
• screenshots with secrets masked;
• sample records before production exports;
• staging or demo artifacts before production artifacts;
• customer-run exports where direct access is unnecessary;
• derived findings instead of retained raw evidence where practical; and
• packet summaries instead of unrestricted source evidence where appropriate.

If a raw artifact is not needed after the issue is understood, we try to reduce it to a redacted summary or remove it from active use.

6. Deletion, Export, and Return

Customers may request deletion or export through support or the applicable agreement path.

Contract-controlled return or deletion may be defined in the SOW, DPA, or ROE. Legal holds may override deletion. Billing, tax, security, audit, and fraud-prevention records may remain where required. Backups may have residual retention for a limited period. Some records may be retained to prevent fraud, abuse, or unauthorized testing. Final deliverables may remain in the customer workspace unless deleted or expired under agreement.

7. Workbench Copilot and AI Records

Workbench Copilot prompts, outputs, and related draft content may be saved with the workspace, intake, packet, project, or report when needed to provide the feature, preserve the review trail, or support the customer.

Commitments:

• customer data is not used to train public AI models;
• AI-assisted outputs may be retained as draft work product or audit or support context;
• customer data submitted through approved service or platform pathways is not authorized for provider model training;
• customers may request restricted or AI-free processing for certain professional services where agreed in writing; and
• restricted material should not be submitted to public or unapproved AI channels.

8. Evidence-Specific Retention

Security evidence is governed by the Evidence Handling Policy and any SOW, DPA, or ROE instructions.

• Raw evidence may be deleted, minimized, or redacted after findings are validated.
• Final reports, remediation records, and contract records may be retained longer.
• Public-safe summaries must not expose restricted evidence or secrets.
• Retention for active testing and red-team evidence may be stricter and should be defined in the ROE or SOW.

9. Customer Responsibilities

Customers should:

• avoid secrets or regulated data in public forms;
• identify sensitive or regulated data;
• mark materials needing special retention or deletion handling;
• avoid uploading unrelated customer records;
• revoke integrations when no longer needed;
• request deletion or export through the proper path; and
• follow their own retention obligations when sharing evidence.

10. Relationship to Other Docs

This policy works with:

• Privacy Policy
• Evidence Handling Policy
• AI Usage Policy
• Customer Data and Model Training
• DPA
• the applicable Statement of Work(/trust-center/contracts/statement-of-work)
• ROE
• the Mutual NDA(/trust-center/contracts/mutual-nda)
• Subprocessors
• Security Practices

If a signed agreement or customer instruction is stricter than this policy for a given engagement, the stricter engagement-specific requirement controls for that engagement.