Information Security Policy

Greymill Limited maintains this policy to protect the confidentiality, integrity and availability of the Greymill platform and of the data our customers trust us with, including financial data received through bank and accounting connections. It is reviewed at least once a year. For how we handle personal data, see our Privacy Policy; for a plain-English overview of our controls, see Security & Trust.

1. Purpose, scope and ownership

• Scope: the Greymill web app and API, our database and storage, our source code repository, our email, billing and AI model providers, our accounting and banking integrations (including Xero and Plaid), and every person or automated agent with access to them, including contractors.
• Owner: the founder is the Information Security Owner. They approve this policy, own the risk register and lead incident response.
• Review: at least once a year, and within 30 days of a material change such as a new integration holding financial data, a new subprocessor, or a security incident.
• Exceptions: written, approved by the owner, time-limited, and logged in the risk register.

2. Data classification and handling

All data is assigned one of four classes. Financial data received through Plaid is always Restricted.

For bank connections made through Plaid we request only the products a shipped feature uses; access tokens never reach the browser; transaction data is never used to train AI models; and when a user disconnects a bank or closes their account we revoke the connection with Plaid and delete the stored tokens and transactions.

3. Access control

The full rules are set out in our Access Control Policy.

• Multi-factor authentication is required on every production and administrative system, including our hosting, database, source code, billing, email and banking-provider dashboards. The Greymill admin console requires TOTP two-factor authentication or a passkey.
• Customer authentication: passwords are hashed with bcrypt, session tokens are stored hashed, and sign-in is rate limited with automatic lockout after repeated failed attempts per account and per IP address. Customers verify their email address, and may sign in with Google, in which case their Google account's own two-step verification applies. Multi-factor authentication is not mandatory for customers.
• Zero-trust access: no system is trusted because of its network location. Every request to production and administrative systems is authenticated and authorised individually, using named accounts with MFA and the least privilege the role needs. Shared accounts are not used.
• Database access: privileged database credentials are used only by server-side code. Every query on customer data is scoped to the authenticated customer.
• Automated coding agents work through pull requests, hold no production secrets, and run tests offline. A human approves every merge.
• Joiners and leavers: access is granted per role and removed within 24 hours of departure, with shared secrets rotated.
• Access review: every quarter, the owner reviews who can reach each system in scope and records the result.

4. Secrets, encryption and infrastructure

• In transit: HTTPS only (TLS 1.2 or higher) for the app, the API, and all calls to third-party providers.
• At rest: the database and its backups are encrypted with AES-256. Third-party access tokens, including bank connection tokens, are additionally encrypted at the field level before they are stored.
• Secrets: API keys and encryption keys are held only in our hosting provider's encrypted environment configuration, never in source code. Production keys are separated from test keys, rotated yearly, and rotated immediately if exposure is suspected.
• Network: cross-origin requests are restricted to the Greymill domain; administrative endpoints require an admin secret plus two-factor authentication; scheduled jobs require a dedicated secret; inbound webhooks are signature-verified.

5. Endpoint security and vulnerability management

• Endpoints: every laptop or device used to access production systems or customer data runs a supported operating system with automatic security updates, full-disk encryption, a screen lock of 5 minutes or less, and active anti-malware protection. Lost or stolen devices are reported immediately and their sessions and credentials revoked.
• Vulnerability scanning: production dependencies are scanned continuously for known vulnerabilities, the public application is scanned at least monthly, and endpoint devices are kept patched through automatic updates checked at each quarterly access review.
• Remediation: critical vulnerabilities are fixed within 7 days, high within 30 days, and medium within 90 days.
• Penetration testing: an independent penetration test of the application is carried out at least once a year and before launching a major integration holding financial data. Findings are tracked to closure in the risk register.

6. Secure development and change management

• Changes reach production only through a reviewed pull request, approved by a human before merge.
• Continuous integration runs the automated test suite with no production secrets and read-only repository permissions.
• Changes that touch authentication, payments, encryption or banking integrations receive a security review before merge.
• Dependencies are pinned by a committed lockfile and monitored for known vulnerabilities, with automated secret scanning on the repository.
• Every deployment is retained, so any release can be rolled back within minutes.

7. Risk management

Risks are identified, rated and tracked in a risk register that the owner reviews every quarter and before any new integration.

1. Identify: at each quarterly review, at each new vendor or integration, and after any incident.
2. Assess: rate likelihood and impact from 1 to 3 each. A combined score of 6 or more is high and requires a dated mitigation.
3. Mitigate: reduce, transfer, avoid or accept. Only the owner may accept a risk, and the acceptance is recorded.
4. Monitor: controls are checked against the evidence described in section 10.

Vendor risk: before a vendor receives Confidential or Restricted data, the owner reviews its security attestation (such as SOC 2 or ISO 27001) and data processing terms, and repeats the review each year.

8. Monitoring, logging and incident response

Authentication and administrative events are logged and monitored on a security operations dashboard, with daily operational reporting. An automated security watch checks every 15 minutes for signs of a possible breach (password guessing, one account used from several places at once, unusual exports or HMRC requests, credentials HMRC refuses, and feedback that reports a security problem) and emails the owner at once, with the 72-hour reporting deadline and what the ICO and HMRC need. Logs never contain Restricted data and are kept for at least 90 days.

1. Detect and log: anyone who suspects an incident reports it to the owner immediately, who opens an incident record.
2. Contain: revoke sessions, rotate affected keys, and disable affected integrations.
3. Assess: establish what data and which customers are affected, and since when.
4. Notify: affected partners (including Plaid, within 24 hours where its data or credentials may be affected), affected customers without undue delay, the ICO within 72 hours where UK GDPR requires it, HM Revenue & Customs within 72 hours where customers' tax data or data obtained through HMRC's APIs may be affected (a ticket with HMRC's Software Developers Support Team, giving the Information Security Owner as the breach contact with a name and telephone number), and US state regulators as their breach laws require.
5. Recover and learn: fix the root cause, complete a post-incident review within 14 days, and update the risk register.

9. People, privacy and consumer consent

• Background checks: employees and contractors with access to production systems or customer data pass a background check, as local law allows, before access is granted.
• Training: everyone with production access completes security awareness training, including phishing and data handling, on joining and every year, and confirms in writing that they have read this policy.
• Confidentiality: staff and contractors sign confidentiality terms before receiving access.
• Consumer consent: customers give explicit consent in the product before any bank account is connected, and are told what data is collected and why, as set out in our Privacy Policy. Customers can disconnect a bank account and request deletion at any time.
• No sale of data: Greymill does not sell consumer data or share it for advertising, and uses financial data only to provide the service the customer asked for.

10. Continuity, retention, training and evidence

Retention periods and disposal methods are set out in full in our Data Retention and Disposal Policy.

• Backups and continuity: daily database backups with point-in-time recovery, instant deployment rollback, and a restore test every year.
• Retention and deletion: data is kept only as long as needed to provide the service or meet legal obligations, in line with UK GDPR and applicable US state privacy laws. A cancelled account's data is deleted 30 days after cancellation by an automated job. Benchmark data is kept only in anonymised bands. Bank connections are revoked on disconnect or account closure.
• Evidence: the owner keeps evidence that these controls operate, including access reviews, risk register reviews, vulnerability scans, penetration test reports, training records, restore tests and incident records, and provides it to partners on request.

11. Contact

To report a vulnerability or security concern, email support@greymill.ai. Next scheduled review: October 2027.

Greymill Limited · Registered in England and Wales · Company number 17144930 · ICO registration ZC120843 · 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ