This page describes the security controls that are actually implemented and active in the Clarity Workflow platform. We only state what we can back up. Where features are still being rolled out, we say so clearly. If you have a question not answered here, contact us.
Account & Access Control
Invitation-Only Registration
New accounts can only be created using a secure invitation link sent by the firm owner. Open self-registration is not available.
Strong Password Requirements
Passwords must meet complexity requirements — minimum 8 characters with uppercase, lowercase, numbers, and special characters. Common passwords are blocked.
Two-Factor Authentication (2FA)
TOTP-based two-factor authentication is available for all accounts and can be required for all users by the firm owner. Backup recovery codes are provided.
Automatic Account Lockout
Accounts are automatically locked after repeated failed login attempts, with a timed cooldown period. You receive an email alert when this occurs.
Role-Based Permissions
A role hierarchy (owner, senior, user, viewer) is enforced server-side on every API request. Each role has clearly defined permissions. Privilege changes require owner approval.
Re-Authentication for Sensitive Actions
Actions such as revoking sessions, changing passwords, and modifying team settings require re-entry of your authenticator code for additional verification.
Data Isolation & Multi-Tenancy
- Firm-scoped isolation. All client records, workflows, documents, variables, and bank analysis data are isolated by your firm. Every database query is scoped to your firm ID — other firms cannot access your data.
- Server-side enforcement, not just UI hiding. Access controls are enforced on every API request by the backend, not only in the user interface. A user cannot bypass access controls by directly calling an API endpoint.
- Strict admin separation. The site-level operator role is completely separate from firm-level roles. Admin access is verified on every request by a live database lookup — it cannot be spoofed by a valid user token alone.
- Session revocation. Sessions are tracked in a database and can be revoked immediately — by you from your Settings page, or by the administrator. Token revocation takes effect on the next API call, not just at JWT expiry.
Data in Transit
- HTTPS enforced for all connections. HTTP requests are automatically and permanently redirected to HTTPS. There is no way to use the application over an unencrypted connection.
- HSTS with one-year max-age. HTTP Strict Transport Security is set with a one-year max-age, includeSubDomains, and preload, instructing browsers to always use HTTPS for this domain.
- TLS 1.3. The server is configured to use TLS 1.3 as the preferred protocol, with TLS 1.2 as the minimum. Older protocol versions are not accepted.
- Cloudflare proxy protection. Traffic passes through Cloudflare's network, which provides DDoS mitigation (SSL/TLS and network-layer), Bot Fight Mode, and the Cloudflare Managed WAF ruleset covering web application exploits, DDoS attacks, bot traffic, and API abuse.
Data Storage & Encryption at Rest
- Application-level field encryption. Sensitive client PII fields (names, contact details, email addresses, phone numbers, and notes) are encrypted using AES-256-GCM before being stored in the database. Each value uses a unique random IV so no two ciphertexts are identical even for the same plaintext.
- Azure platform-managed disk encryption. The virtual machine hosting the application uses Azure platform-managed key disk encryption, meaning the underlying VM disk is encrypted at rest at the infrastructure level in addition to application-level encryption.
- Files stored in private Azure Blob Storage. All uploaded files (documents, bank statements, templates) are stored in private Azure Blob Storage containers. Containers are configured with anonymous access disabled — blobs cannot be accessed without authentication.
- Short-lived access links. When a file needs to be downloaded, a time-limited SAS (Shared Access Signature) URL is generated on-demand (15 minutes by default). There are no permanent public file links.
- Encrypted backups. Database backups are encrypted with AES-256-GCM before storage. Backup encryption keys are managed separately from the application. A checksum is recorded for each backup to support integrity verification.
File Upload & Document Security
- File type validation. Uploaded files are checked against an allowlist of permitted file types (PDF, CSV, OFX, DOCX). Both the file extension and MIME type are checked. Files that do not match are rejected and quarantined.
- Malware scanning via Azure Defender for Storage. Azure Defender for Storage is enabled on the storage account, providing automatic malware scanning on uploaded blobs. Files detected as malicious are not served to users.
-
Path traversal prevention. File names are sanitised before storage. Directory traversal patterns (e.g.
../) are stripped and blocked in both upload and download code paths. - File size limits. Upload sizes are enforced at both the application and server level to prevent resource exhaustion.
- Authenticated download only. Files can only be downloaded by authenticated users who have access to the associated client record. File access is checked server-side before any link is generated.
Infrastructure & Hosting
| Component | Detail | Status |
|---|---|---|
| Cloud Provider | Microsoft Azure — Australia East region | Active |
| Compute | Azure Virtual Machine with platform-managed disk encryption | Active |
| File Storage | Azure Blob Storage — all containers private, anonymous access disabled | Active |
| CDN & DDoS Protection | Cloudflare proxy — SSL/TLS DDoS protection, Network-layer DDoS mitigation | Active |
| Web Application Firewall | Cloudflare Managed WAF Ruleset (web application exploits, DDoS, bot traffic, API abuse) | Active |
| Bot Protection | Cloudflare Bot Fight Mode with JS detections | Active |
| Malware Scanning | Azure Defender for Storage — On-Upload Malware Scanning | Active |
| Error Monitoring | Sentry — real-time exception tracking and alerting | Active |
| Performance Monitoring | Azure Application Insights — request tracing, failure rate, availability monitoring | Active |
| Alerting | Azure Monitor alert rules — VM availability, CPU, memory, disk, failed requests, server exceptions | Active |
| TLS Version | TLS 1.3 preferred, TLS 1.2 minimum. Older versions blocked. | Active |
| Secret Management | Azure Key Vault — encryption keys and credentials stored outside the codebase, loaded at startup via Managed Identity | Active |
| Email Authentication | SPF, DKIM, and DMARC (p=quarantine) — prevents spoofing of notification and security emails from this domain | Active |
Audit Logging & Accountability
- Comprehensive action logging. All significant actions are recorded — logins (successful and failed), data creation and modification, document access and downloads, user management changes, MFA events, session activity, and admin actions.
- Audit records include. Timestamp, user identity, firm ID, action type, affected record, IP address, and user agent. This provides the information needed to investigate incidents or answer compliance questions.
- Admin audit visibility. The site administrator has access to an audit log viewer showing all security events across the platform.
- Automated retention. Audit log records are retained in accordance with the configured data retention policy. Records of data deletion events are kept for an extended period for regulatory compliance.
Application Security Controls
Rate Limiting
All API endpoints are rate-limited. Authentication endpoints have stricter limits to prevent brute-force attacks. Limits are enforced both at the application layer and at the Cloudflare network layer.
Security Headers
All responses include a strict Content Security Policy (CSP) with per-request nonces, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers.
Input Validation
All API inputs are validated server-side. The application rejects invalid Content-Types, oversized payloads, and malformed data before processing.
XSS Protection
User-supplied data is HTML-escaped before insertion into the DOM. Inline scripts in HTML responses use per-request CSP nonces to prevent code injection. Dangerous HTML is parsed in inert documents, not live DOM.
Secure Session Handling
Session tokens are validated against the database on every request. Expired, revoked, or force-logged-out sessions are rejected immediately. Session expiry warnings appear 5 minutes before automatic logout.
Secrets Management
All secrets (JWT signing keys, encryption keys, API credentials) are stored in Azure Key Vault and loaded at startup via Managed Identity. No secrets are stored in the codebase or source control.
Backups & Recovery
- Automated database backups. The database is backed up on a scheduled basis. Each backup is encrypted with AES-256-GCM before storage and includes a SHA-256 checksum for integrity verification.
- Azure VM backup policy. The virtual machine is enrolled in an Azure Backup policy providing additional infrastructure-level recovery capability.
- Data retention policy. Data is retained in accordance with a configurable retention policy. Permanent deletion of records is logged in the audit trail with timestamp and operator identity for regulatory accountability.
Responsible Disclosure
Report a Security Vulnerability
If you discover a security vulnerability in Clarity Workflow, we want to know about it. Please report it to us privately so we can address it before it can be exploited.
Email: admin@clarityworkflow.com
Response commitment: We will acknowledge receipt within 2 business days and provide a status update within 7 business days.
Please include a description of the vulnerability, the steps to reproduce it, and any evidence you have collected. We will not take legal action against researchers who act in good faith.
A machine-readable disclosure policy is published at /.well-known/security.txt in accordance with RFC 9116.
Honest Limitations
We believe in being transparent about what is and is not yet in place, rather than overstating our security posture. The items below are in-progress or planned, alongside controls that have recently been completed:
- Independent penetration testing. We have not yet commissioned an independent security penetration test. This is planned. Until it has been completed, we cannot claim our security has been independently verified by a third party.
- DMARC email authentication. SPF, DKIM, and DMARC records are all configured for outbound email from this domain, preventing spoofing of Clarity Workflow notification and security emails.
- Formal compliance certifications. The platform is built with compliance principles in mind (data isolation, audit logging, encryption, access control) but has not yet undergone formal certification (e.g. SOC 2, ISO 27001). These are on the roadmap.
Questions & Contact
If you have a question about security that isn't answered here, or if you are a prospective user evaluating Clarity Workflow for use with sensitive client matter data, we are happy to discuss our architecture and controls in more detail.
Security Contact
For vulnerability reports or security questions: admin@clarityworkflow.com
General Support
For all other questions, use the in-app Support page or contact us through your registered email address.