Information Security Policy

1. Purpose

This policy establishes the framework for protecting the confidentiality, integrity, and availability of information assets at Athena Workflow. It applies to all systems, personnel, and third-party integrations — including the Plaid bank-feed and QuickBooks accounting integrations — that process, store, or transmit firm and client financial data.

2. Scope

This policy applies to:

• All employees, contractors, and administrators with access to production systems
• The firm dashboard, the client portal and every public and private API they rely on
• All data received from third-party financial data providers (Plaid, Intuit)
• All personal and financial information stored or processed by the platform

3. Roles and Responsibilities

3.1 Role hierarchy — the platform enforces a four-tier staff role model, plus a separate client identity:

3.2 Access enforcement

• Access control is enforced through a single Role-Based Access Control (RBAC) registry. Every sensitive action is named, has a minimum role, and can additionally be denied per user by a manager.
• Every data query is scoped to the authenticated user's firm; client sessions are further confined to the client-portal API surface and fail closed on every other endpoint.
• Actions (view, create, update, delete, close, amend) are gated explicitly on the server; the user interface only hides what the server already refuses.
• Least privilege is the default: an action that is not registered is not permitted.
• Access changes and privileged actions (closing or amending accounting periods, deleting clients, releasing suppressed e-mail addresses) are written to the audit log with the acting user.

4. Authentication

4.1 Account authentication

• Staff and client accounts authenticate with an e-mail address and password over a server-side session; plaintext passwords are never stored — only salted bcrypt hashes.
• Passwords must be at least 10 characters and contain an uppercase letter, a lowercase letter, a number and a symbol. The rule is enforced on every path that sets a password, and system-generated passwords meet the same bar.
• Accounts are locked for 30 minutes after 6 consecutive failed sign-in attempts; the account holder is notified by e-mail, the lock clears on its own, and a platform administrator can clear it earlier.
• Sessions expire after 30 minutes of inactivity. Signing out invalidates the session immediately, including any request already in flight.
• New firm accounts must confirm their e-mail address before they can sign in.

4.2 Additional sign-in factors

• Staff accounts can enable an e-mail one-time-code second factor from their account security settings. When enabled, every sign-in requires a code delivered to the account e-mail address; codes expire after 10 minutes and a limited number of incorrect codes cancels the challenge.
• Enabling or disabling the second factor is recorded in the audit log.
• The second factor is optional per account. Authenticator-app and SMS factors are not offered at this time; this policy will be updated before any new factor is enabled.

5. Data Encryption

5.1 Encryption in transit

• All client–server communication uses HTTPS with TLS 1.2 or higher; plain HTTP is redirected to HTTPS at the edge.
• HTTP Strict Transport Security (HSTS) is sent on every response with a two-year max-age.
• A Content Security Policy restricts resource origins, and referrer and permissions policies limit what the browser shares with third parties.
• Outbound calls to Plaid, Intuit, Stripe and the e-mail provider are made over TLS only.

5.2 Encryption at rest

• Databases, document storage and backups are encrypted at rest by the hosting provider using AES-256.
• Bank-feed access tokens and third-party integration credentials (QuickBooks OAuth tokens, payment and storage keys) are additionally encrypted field-by-field with AES-256-GCM before they are written.
• Field-encryption keys are derived with PBKDF2 from secrets held only in the runtime environment; they are never committed to the codebase.
• Nightly full-system backups are encrypted and written to a separate storage account.

6. Vulnerability and Patch Management

• Static analysis: an automated security scan checks every API route for a server-side authorization gate and flags raw SQL, dynamic code evaluation and unsafe HTML injection. Every accepted exception is recorded with a written reason.
• Security linting runs on every verification pass.
• Dependency scanning: the dependency tree is audited for known vulnerabilities; findings are tracked and remediated in order of severity.
• Automated test suites (unit, API and end-to-end, on desktop and mobile viewports) must pass before any release.
• Every release is built, verified and deployed through the same pipeline to a sandbox host and the production host.

7. Access to Production Systems

• Production credentials are managed exclusively through environment configuration and an encrypted credentials store; no secrets are committed to version control or written to logs.
• Access to production infrastructure is restricted to authorized personnel only.
• Platform-level administration (firms, subscriptions, platform credentials, e-mail suppression) is confined to the Platform Admin role.
• Session cookies are HTTP-only, Secure and same-site, and every state-changing request is bound to the signed session.
• Private pages and API responses are served with cache-control headers that prevent sensitive data from being cached by browsers or proxies.

8. Third-Party Financial Data (Plaid and QuickBooks)

• Bank data is accessed exclusively through the Plaid API using access tokens; bank credentials are entered on Plaid and never reach Athena Workflow.
• Access tokens are encrypted at rest immediately upon receipt (see Section 5.2).
• Explicit client consent is obtained and recorded before any bank connection is started: the consent timestamp, IP address and user agent are stored with each connection, and consent is validated server-side before the token exchange.
• Clients can disconnect a bank account at any time, which removes the stored access token.
• QuickBooks connections use Intuit OAuth; tokens are encrypted at rest and the connection can be revoked from the firm dashboard.

9. Incident Response

In the event of a suspected security incident:

1. The incident is escalated to the responsible engineering team immediately.
2. Affected credentials or tokens are rotated as a first response measure; affected sessions are revoked.
3. Affected firms and clients are notified within 48 hours, in accordance with applicable law and the notification requirements of our financial data providers.
4. A post-incident review is conducted to identify the root cause and the remediation steps, and this policy is updated where needed.

Suspected incidents and vulnerability reports can be sent to [email protected].

10. Policy Review

This policy is reviewed at least annually, or following any significant change to systems, personnel, or applicable legal and regulatory requirements.