Secure Delete

Secure Delete

At Praetorian, we treat removal of customer and temporary platform data as a first-class operational control. Deletion is implemented in our cloud architecture using standard AWS APIs and coordinated cleanup across storage and identity layers—not host-level file shredding utilities (for example, Sysinternals SDelete or similar disk-wipe tools are not part of this data path).

Object storage (Amazon S3)

User-associated files and other objects stored in S3 are removed using the standard Amazon S3 deletion API (DeleteObjects and related S3 delete operations). This is the normal, supported way to delete objects in object storage: objects are removed from the bucket and are no longer served or listed for the application after successful deletion. This approach matches how managed object storage is designed to be operated at scale and integrates with AWS access controls, logging, and replication settings where applicable.

Comprehensive account cleanup

For account deletion and full tenant teardown, we run a multi-layer cleanup so data and credentials are removed consistently across services, not only from file storage. The workflow addresses, in order:

  1. DynamoDB — application and metadata records tied to the account.
  2. Neo4j — graph data and relationships associated with the account.
  3. S3 — objects (including proof files and other stored artifacts) for that account.
  4. AWS Systems Manager (SSM) Parameter Store — parameters such as per-tenant or per-user secrets and configuration material that must not outlive the account.
  5. Amazon Cognito — user pool identities and authentication state so login and session artifacts are retired with the account.

Automation and service logic ensure these steps are applied as part of the same deletion lifecycle, reducing the risk of orphaned records, stale graph edges, leftover objects, or active credentials after an account is closed.

Production safeguards

In production, DynamoDB deletion protection is enabled on relevant tables so tables cannot be dropped accidentally. This guardrail applies to infrastructure lifecycle operations; it complements application-driven item- and account-level deletion performed through controlled deletion workflows.

Audit and verification

Deletion and cleanup steps are executed through defined platform processes and are observable through AWS and application logging (for example, API calls and workflow outcomes), supporting audit review and verification that removal ran as intended.

Summary

AreaApproach
S3 objectsStandard S3 delete APIs (DeleteObjects / equivalent batch delete paths)
Account removalEnd-to-end cleanup: DynamoDB → Neo4j → S3 → SSM Parameter Store → Cognito
DynamoDB (production)Deletion protection on tables; controlled per-record / per-account deletion via workflows

This model reflects cloud-native deletion: cryptographic erasure of underlying physical media is owned by the AWS shared responsibility model for the storage service, while we own correct, complete removal of customer data and keys from our application and identity footprint through the layers above.