Media Handling and Data Disposal Policy

Organization: Strategic Habits Consulting, LLC, doing business as Gevell and TheAccessible.Org Owner: Larry Anglin, CTO Effective date: 2026-09-23 Parent policy: Information Security Policy

1. Purpose and scope

This policy sets how the Company:

handles storage media that may hold customer data or Company secrets;
cleans that media before it is reused;
destroys it at end of life;
deletes customer data when asked.

It covers:

cloud storage: Cloudflare R2, AWS S3 and Supabase;
the Company’s AWS EC2 processing servers;
staff laptops, which are personally owned (see the Information Security Policy §7);
any drive or device removed from them.

2. Media handling

No removable media for customer data. Customer documents and customer data must not be written to USB drives, external disks, optical media or other removable media. Customer data lives only in the production systems named in the Information Security Policy.
No customer data on laptops in normal operation. Staff do not download or view customer documents as part of normal work.
- If a customer asks for help and gives written permission for us to handle a specific document, it may be kept on the staff member’s encrypted work laptop only for as long as the task takes. It is then deleted, and the deletion is noted on the support ticket.
- Development and testing use test documents and the public test corpus (Information Security Policy §3), never customer data. Corpus documents come from public websites, not from the service, so a document published by an organization that is, or later becomes, a customer is corpus data, not customer data.
Encryption at rest. EC2 processing servers use encrypted EBS volumes, and staff laptops use full-disk encryption. Cloud stores encrypt data at rest with AES-256 using provider-managed keys.
Transient processing. Processing servers hold customer documents only while they are being processed. When an instance is terminated, its EBS volumes are deleted and sanitized by AWS.

3. Cloud storage sanitization

The Company does not own the physical media behind AWS, Cloudflare or Supabase. Cleaning and destroying that media is the provider’s job. Each provider’s SOC 2 report describes media sanitization in line with NIST SP 800-88. The Company relies on those controls and checks the providers’ current attestations during the annual subprocessor review.

4. Devices used for Company work: reuse and end of life

Staff laptops are personally owned; the Company’s requirements for them are in the Information Security Policy §7. This section also applies to any Company-owned hardware. Cloud compute (EC2 instances and volumes) is covered by §3: the provider sanitizes it.

Modern laptops (including Apple-silicon Macs) have storage soldered to the logic board, and it is always hardware-encrypted, with the keys held in the device’s security chip. Sanitizing such a device means cryptographic erase: destroying those keys, which leaves the stored data as unrecoverable ciphertext. The device itself stays usable. Customer data is not kept on laptops in normal operation (§2), so the main thing to protect on a laptop is the credentials it holds.

Event	Required action (NIST SP 800-88 Rev. 1)
Company-owned device repurposed (for example, it moves to another person)	Purge by cryptographic erase: use the operating system’s built-in “Erase All Content and Settings” (or equivalent secure reset). For Linux servers, wipe the LUKS key slots and header, then reinstall.
A personally owned work laptop leaves the owner’s possession (sale, trade-in, gift or recycling)	The owner first removes Company accounts, credentials and files, then purges the device as above, removes it from their Find My / Activation Lock, and confirms in writing.
The owner leaves the Company but keeps the laptop	No wipe. The person removes all Company accounts, sessions, passkeys, SSH keys and Company files (source checkouts, `.env` files), and confirms in writing. The CTO revokes the device’s sessions from the Company side.
Company-owned device leaves Company control	Purge as above, remove it from the Company’s Find My / Activation Lock, and check that it boots to a blank setup screen.
Laptop that fails or won’t boot	Erase it from recovery mode, or restore it with the manufacturer’s tool (for a Mac, a DFU restore with Apple Configurator), either of which performs a cryptographic erase. If it can’t be erased, send it only to the manufacturer or an authorized service provider. Its storage stays encrypted and can’t be read without the user’s credentials. In every case, first revoke or rotate the credentials that were on the device (SSH keys, API tokens, browser sessions, password-manager sessions). The repaired device can go back into service.
Removable or replaceable drive that fails (external SSDs, server disks)	Cryptographic erase if the drive still responds. If it doesn’t, destroy it (shred or drill), or use a certified disposal vendor that issues a certificate of destruction. Keep it in locked storage until then. Because the drive was encrypted, what remains is ciphertext.

Every purge, repair hand-off or destruction is recorded in the disposal log (§6).

5. Customer data deletion

Individual files. A customer can delete a file at any time in the application. This deletes the stored original and its converted outputs from object storage, along with the database record.
Account deletion.
1. The customer requests deletion. The account is locked right away and scheduled for deletion 30 days later. The customer can restore it during that time.
2. After 30 days, a daily automated job permanently deletes the account’s stored files and database rows, removes the customer’s personal data from their Stripe customer record, and deletes the login.
3. The job writes an append-only audit record. The record holds a hashed user ID, timestamps and deletion counts, and no personal data.
- Design: the account-deletion design document.
Institutional requests and contract end. When an institution asks, or when a contract ends, the Company deletes that institution’s data within 30 days. It then confirms the deletion in writing to the institution’s contact.
Backups and logs age out.
- Deleted data can remain in Supabase’s daily database backups until those backups expire under Supabase’s retention schedule.
- Application logs, which hold metadata only, are kept for 30 days.
- Encrypted operational backups in Backblaze B2 are kept for 30 days and contain no customer documents.
- Backups are not edited to remove single records. They expire on their normal schedule and are not restored except for disaster recovery.
Short-lived processing copies.
- Files in the AWS S3 malware-scan staging bucket expire after 1 day.
- Raw emails received by the convert-by-email feature expire after 7 days.

6. Disposal record

Every disposal is logged in the disposal log with:

the date;
the asset (type, serial number or hostname);
what data it held;
the method used (crypto-erase, Purge or Destroy);
who did it;
the vendor certificate, where there is one.

This covers device and drive disposals, and institution-level deletions under §5. Individual customer account deletions are recorded automatically in the deletion audit table.

Actions required to make this policy true

Create docs/admin/security/disposal-log.md. No disposal record exists today. Log any drives already retired or failed, for example the development-server disk that failed on 2026-09-08. Then dispose of them under §4.
Check full-disk encryption on every device in scope. That means every laptop, every EC2 processing server (EBS encryption), and any other server or CI runner that might ever hold customer data. Record the results, as a simple device inventory, in the disposal log or access register.
Confirm the account-deletion job removes every derived object, not only the original and output. The job deletes the keys files.r2_key and files.output_r2_key. Check whether these are also removed or left orphaned:
- HTML version snapshots (html_edits.version_r2_key);
- chunk and intermediate artifacts;
- data held by other Gevell apps, such as Forms, Org Chart and Course Map. Do the same check for single-file deletion.
Record the Supabase backup retention period for the project’s plan, and state it in §5 in place of the general wording.
Confirm lifecycle rules for S3 processing buckets not managed in CDK. Only the malware-scan staging bucket (1 day) and the email bucket (7 days) have lifecycle rules in infra/cdk. Check whether customer documents that pass through the processing S3 bucket expire. Also check that the processing server cleans up its temporary files after each job.
Write the institution deletion-confirmation procedure from §5 and a template for the written confirmation. Neither exists today.
Confirm no customer documents are on laptops or development machines today, and that the local development stack uses only test documents and the public test corpus.