Our Approach
dashboardWISE processes operational and financial information from law firm systems, so security is designed into account access, integration handling, infrastructure and deployment. We use layered controls to reduce the likelihood and impact of unauthorised access, data loss and service interruption.
This page describes current product and infrastructure controls. It is not a certification report and does not claim controls that have not been independently verified.
Infrastructure and Network
- The production application runs on Amazon Web Services in the
us-west-1region. - AWS CloudFront terminates public TLS traffic and routes application requests to a load balancer over HTTPS.
- The load balancer accepts application traffic only from the AWS CloudFront origin facing network.
- Application services accept inbound application traffic only from the load balancer or authorised internal services.
- The PostgreSQL database is not publicly accessible and runs in isolated network subnets.
- Object storage blocks public access and requires encrypted transport.
Encryption and Secrets
- Production database storage, backups and customer asset storage are encrypted at rest using AWS managed encryption.
- Public website and application traffic uses TLS in transit.
- OAuth credentials for connected practice management systems are encrypted with AES 256 GCM before database storage.
- Two factor authenticator secrets are encrypted and recovery codes are stored as hashes.
- Production secrets are supplied through AWS managed secret and parameter services rather than committed to source code.
Identity and Access
- Sign in uses time limited email verification codes rather than stored application passwords.
- Optional authenticator based two factor authentication is available for product users.
- Session, onboarding and integration authorisation cookies use protected attributes appropriate to their role.
- Firm administrators can assign roles and detailed permissions to authorised users.
- Production deployment uses a scoped GitHub identity and service specific AWS permissions.
Customer Data Isolation
Customer access is derived from the authenticated user’s firm membership on the server. Product requests do not trust a browser supplied firm identifier as proof of access. Data reads preserve firm, practice management source and permission boundaries.
Synchronised records are attached to a firm and data source. Reporting calculations publish completed generations so partially refreshed data is not presented as a completed update.
Operations and Monitoring
- Application and worker events are logged for diagnosis and security monitoring, with sensitive contact information masked where used in authentication logs.
- Infrastructure alarms monitor queue failures, service health, database pressure and storage conditions.
- Background work uses bounded retries, dead letter handling and idempotent processing to limit repeated or partial operations.
- Authentication and sensitive routes use origin checks, rate limits, signed state and constant time secret comparison where applicable.
- Provider webhooks are validated and handled as change notifications, with scheduled reconciliation used for completeness.
Resilience and Recovery
- The production database has encrypted automated backups with a seven day retention period and deletion protection.
- Customer asset storage is encrypted, versioned and protected from public access.
- Application deployments use health checks, rolling replacement and an automatic deployment circuit breaker.
- Failed background messages move to a dead letter queue for investigation rather than being discarded silently.
- A maintenance response is available for temporary application origin failures.
Software Delivery
Changes are reviewed through short lived branches and automated checks covering formatting, types, contracts and release behaviour. Production deployment is separated from normal development and uses controlled infrastructure changes, backward compatible database migrations and post deployment health checks.
Shared Responsibility
Customers are responsible for:
- authorising only users who need access;
- assigning suitable roles and reviewing access regularly;
- protecting email accounts and authentication devices;
- configuring and disconnecting practice management integrations; and
- reporting suspected compromise and removing access promptly when a user leaves.
Assurance and Questions
dashboardWISE does not currently claim SOC 2 or ISO 27001 certification on this page. Security information for customer reviews can be requested from support@dashboardwise.com. Requests may be subject to confidentiality and reasonable scope limits.