Security & data protection
Trust you can verify, not just read about
Grant data is sensitive: unsuccessful applicants, financial details, safeguarding narratives. Grantledger's security posture is built into the architecture, and most of it is verifiable from inside the product.
Tenant isolation the database enforces
Every grant table runs under PostgreSQL row-level security with FORCE enabled, isolation between funders is enforced by the database engine itself, not by application code remembering a WHERE clause. Cross-tenant access is covered by automated tests on every change.
A tamper-evident audit chain
Sensitive transitions (decisions, awards, agreement acceptance, condition sign-offs, every payment step, report reviews, undos, imports, and erasures) append to a per-funder SHA-256 hash chain. The console verifies the chain on demand and reports the exact row if anything has been altered.
A strict AI boundary
Scoring and analysis are decision support only: grounded in submitted evidence, cited, and marked as such. No code path auto-rejects, auto-awards, or sends a consequential communication without a human. Applicant text passes a PII firewall before any model-facing processing.
UK GDPR rights, implemented
The funder is the data controller; Grantledger processes on their instruction. Right to erasure is a working feature: identity and free text are removed across applications, scores, reports, CRM, and published 360Giving data, preserving only non-identifiable financial aggregates, and the erasure itself is audit-chained.
First-party authentication
Sessions use asymmetric RS256 tokens verified against a published key set; passwords are stored with scrypt. Enterprise single sign-on via OIDC is available on Enterprise plans.
No banking credentials
Grantledger records payment approvals, instructions, and confirmations and reconciles against your bank's CSV export. It never holds credentials that could move money.
Sub-processors
Who else touches the data, and why
We keep this list current. Each sub-processor is bound by data-protection terms no less protective than our own, and we tell controllers before we add or change one.
| Provider | Purpose | Applicant data? |
|---|---|---|
| Hosting & database | Runs the application and stores your data, in your market's region | Yes — encrypted, region-pinned |
| Transactional email | Decision notices, reminders, reviewer invites | Names & email addresses only |
| Stripe | Subscription billing | No — never |
| AI provider (if enabled) | Decision-support scoring | PII-redacted input only |
| Microsoft Clarity | Aggregate heatmaps on the public marketing site | No — marketing pages only, never the console or applicant pages |
Accessibility
We build to WCAG 2.1 AA. Applicant and grantee pages are public and often used by small charities on phones, so semantic landmarks, labelled fields with linked error messages, visible focus, status-region announcements and reduced-motion support are part of the product, not an afterthought. Automated accessibility checks (axe) run in our test suite. If you hit a barrier, tell us and we will fix it.
Data-protection documents
Everything a cautious buyer asks for
We provide, on request, a Data Processing Addendum, a DPIA template pre-filled for the Grantledger processing, a per-market data-residency statement, and our internal security assessment. The funder is always the data controller; we process only on your instruction. Right to erasure and data export are working features in the console, not promises.
Honest about what's external
Independent penetration testing and Cyber Essentials certification are on our launch roadmap and will be published here when the certificates exist. We don't claim external assurance before it's real. The internal posture above is verifiable today: ask us for the test evidence, or run the audit-chain verification yourself from the console.