How RCRAReady protects your records

2.1 Where your data lives

Application data and uploaded files are stored on AWS in the United States (US East region). The database keeps copies across multiple availability zones, so losing one data center does not lose data or take the service offline. The web app is served through Cloudflare.

2.2 Backups and recovery

• The production database is backed up continuously through AWS Backup, with a daily backup as a fallback.
• Stored files are versioned. Overwriting or deleting a file keeps the earlier version.
• Automatic safeguards stop any release that would replace the database or file storage.

2.3 Monitoring

• Automated alarms cover application errors, performance, and delivery of email and SMS alerts.
• A separate check confirms that deadline alerts are running. If they stop, we find out before you miss one.
• An automated test signs in to the live app after every release and on a regular schedule.

3.1 Sign-in without passwords

People sign in with a code sent to their work email, a magic link, or a Google or Microsoft account. Password sign-in is switched off, so there are no RCRAReady passwords to reuse, phish, or leak.

• Emailed sign-in codes and links are single-use and expire after 10 minutes.
• Google and Microsoft sign-in tokens are encrypted before they are stored.
• Sign-in activity is recorded in a separate authentication log.

3.2 Roles

There are three roles. Each can be granted for the whole organization or for specific facilities, so a contractor at one site sees only that site.

3.3 How permission checks are enforced

Every permission decision goes through one central policy, and the build fails if code checks access any other way. Automated tests check that one organization's data and alerts never reach another organization.

3.4 Access to production

• Production is isolated from development and testing environments.
• Multi-factor authentication is required on every account that can reach production systems.
• Deployments and services reach AWS and the database with short-lived credentials, not stored keys or passwords.
• Policy prohibits using production customer data in development or test environments.

4.1 In transit

The app accepts TLS 1.2 and 1.3 only, and uses HSTS so browsers never fall back to plain HTTP. A strict Content Security Policy limits which scripts can run and prevents the app from being embedded in other sites.

4.2 At rest

• Database storage is encrypted with AES-256 through AWS KMS, with automatic key rotation.
• Stored files are encrypted with AES-256 server-side encryption.
• If you connect EPA RCRAInfo, your API credentials are encrypted a second time by the application before they are stored.

4.3 Files and attachments

• Files are private. The app shares them only through short-lived signed links.
• Temporary uploads are deleted after 1 day. Documents uploaded for AI extraction and never attached to a waste profile are deleted after 7 days.

4.4 Logs and secrets

• Credentials and tokens are redacted before anything is logged, and email addresses are masked.
• Third-party credentials are stored as encrypted secrets and never appear in source code.

5.1 Append-only, enforced by the database

An audit log is only as trustworthy as the guarantee that nobody can edit it. In RCRAReady that guarantee is a database permission, not a policy. The access the application runs with can add audit entries and read them, but the database refuses any attempt to change or delete them, so neither the app nor a bug in it can rewrite history.

5.2 What each event records

Each change to a container, inspection, shipment, profile, or setting writes an event with who made it, their role at the time, when, where it came from (web, import, scheduled job, or webhook), and a snapshot of the record and facility after the change.

5.3 Deadlines you can reproduce

Accumulation deadlines and generator status are calculated by fixed rules, not AI, so the same inputs always produce the same dates. Build checks stop those rules from depending on server clocks or time zones. The app shows the inputs and regulation behind each date.

5.4 How the rules are tested

Alongside ordinary tests, the core rules (generator category, accumulation limits, and deadlines) have property-based tests. Instead of checking a few hand-picked examples, each test generates hundreds of random waste quantities, containers, and dates, and checks that rules like these hold for every one:

• Generator category matches an independent implementation of the federal thresholds in 40 CFR 262.13.
• Adding hazardous waste can never make a generator category less strict.
• Splitting, reordering, or changing the units of the same waste never changes totals, category, or limits.
• Missing information never produces a later deadline than the exact one.

5.5 e-Manifest access is read-only

RCRAReady's connection to EPA RCRAInfo only looks up, searches, and downloads manifests and attachments. It has no ability to create, sign, correct, or submit a manifest, so nothing is filed with EPA in your name.

5.6 Exports and retention

• Containers, shipments, profiles, and audit history export as CSV or PDF at any time, including an audit summary built for inspections.
• Compliance records are kept for three years unless you ask otherwise, subject to legal and operational requirements.