Security, Infrastructure & OperationsRisk Management
Risk Register
12 identified risks with likelihood, impact, controls, and residual risk — Shared model
The risk register below covers the Shared model (multi-tenant). Current version: 1.0 | Approval date: 2026-04-29. Review: annually or upon significant architectural change.
Rating scale: L = Low · M = Medium · H = High
Risk Register
| # | Risk | Likelihood | Impact | Controls in place | Residual risk |
|---|---|---|---|---|---|
| 1 | Unauthorized account access | M | H | Username and password authentication, with passwords stored hashed; 8–128 character password policy; account lockout after 10 failed attempts, with a counter shared between both factors; optional TOTP 2FA (code from an authenticator app or sent by email), which the organization can enforce; no backup codes — a 2FA reset requires two independent requests (user + Super User), through separate channels; per-tenant OIDC SSO option for federated identity | Low |
| 2 | Unauthorized access to documents in object storage | L | H | S3 access exclusively through authenticated API; Block Public Access enabled; server-side encryption (SSE); versioning enabled; replica is backup-only, with no application access | Low |
| 3 | Data loss — relational data | L | H | Heroku Postgres managed Point-in-Time Recovery (continuous WAL) + daily snapshots with 30-day retention; restore capability validated periodically | Low |
| 4 | Data loss — documents | L | H | S3 versioning enabled (recovery after accidental deletion/overwrite); cross-region replication to a separate AWS region; 100-day delete-marker lifecycle; optional daily export per tenant to an external archive controlled by the tenant (cloud storage, qualified e-archive) | Low |
| 5 | Service unavailability / capacity exhaustion | M | M | Heroku autoscaling web dynos and worker dynos (asynchronous jobs); managed Postgres and Redis with provider-assured availability; New Relic monitoring with NRQL alerts on application errors | Low |
| 6 | Deployment failure / code integrity | L | M | GitHub branch protection on main (mandatory PR review); changes tested in staging before merge; automated build & release GitHub → Heroku; versioned releases with one-click rollback | Low |
| 7 | Secret / credential exposure | L | H | Secrets stored exclusively in Heroku config vars — never committed to source; access scoped per environment; mandatory 2FA on GitHub, Heroku, AWS, and other administrative consoles | Low |
| 8 | Vulnerable dependencies / insecure code | M | M | Static application security testing (SAST); software composition analysis (SCA) scanning on server-side and client-side dependencies; findings are triaged and remediated within the development cycle | Low |
| 9 | Audit log tampering / signing trail loss | L | H | Signing audit trail written to AWS CloudWatch Logs (append-only, encrypted at rest, 5-year retention); customer activity logs retained in Postgres for 3 months, downloadable by tenant administrators | Low |
| 10 | Third-party / sub-processor compromise | L | M | TLS in transit with all providers (Postmark, e-signature provider, New Relic, Sentry); e-signature provider authenticated via mTLS or API token; credentials limited per provider; vendor due diligence at selection | Low |
| 11 | Compliance — data retention and data subject rights | L | M | Defined retention windows (signing logs 5 years; activity logs 3 months; PG backups 30 days; S3 delete-markers 100 days); documented GDPR data subject request procedure; self-service download of activity logs by tenant admin; optional daily export per tenant for data portability | Low |
| 12 | Network / transport security | L | M | HTTPS/TLS 1.2+ enforced at the Heroku Router; Let's Encrypt certificates with automatic renewal; internal Heroku traffic confined to a private network with TLS in transit | Low |