Security Whitepaper

Last Updated: May 19, 2026

Clerke is a service of Fileflow Solutions Inc.("Clerke", "we", "us", or "our"), operating under the brand name “Clerke.” This document describes how Clerke protects the personal information and confidential content handled on behalf of the BC paralegals and lawyers who use the service. It is intentionally short and direct. Where firms need more detail (for example, before signing a Data Processing Agreement), Clerke provides supplementary documentation on request.

Why this document exists

Clerke is used by paralegals and lawyers to review minute books and to maintain ongoing entity records on behalf of corporate clients. The contents handled by the service — minute book PDFs, entity records, Transparency Register data, generated documents, and document signing audit information — are often subject to solicitor-client privilege and contain personal information about directors, officers, shareholders, and significant individuals.

Summary

Architecture

Clerke is structured to keep the parts of customer data the service directly controls — accounts, uploaded files, generated reports, audit logs — within Canadian infrastructure. AI processing is the only step where minute book content leaves Canada, and it is governed by Anthropic's Commercial Terms (which prohibit training on customer content) and, where signed, a Zero Data Retention addendum that further limits retention on Anthropic's systems.

Data flow

1. The file is uploaded over TLS directly to Canadian-resident storage (Supabase, Montreal).
2. Clerke's server reads the file, validates it (size limits, file-type verification by inspecting the file's actual contents, not just its extension), and creates a database record.
3. The file content is sent to Anthropic for analysis. Anthropic is contractually prohibited from using the content to train models.
4. The structured report is returned and stored in Canadian infrastructure.
5. The source PDF is deleted from storage shortly after the report is saved, in any case within 24 hours.
6. The action is recorded in an audit log.

Where data lives

Document signing — tamper evidence

• At document generation, Clerke computes a SHA-256 hash of the unsigned PDF and stores it alongside the file.
• Before signing, Clerke re-fetches the unsigned PDF and recomputes its SHA-256. If the recomputed hash does not match the stored hash, the signing operation is aborted.
• The signing event records the SHA-256 of the signed PDF as well, so future audits can verify the exact bytes the signer attested to.
• One signature per document is enforced at the database level. Re-signing or voiding a signed document is not supported in this version.

For external signing, access to the document is controlled by a one-time tokenized URL. The token is a 32-byte random value, expires 14 days after issuance, and is consumed (marked single-use) the moment the signing event is recorded.

Encryption

• In transit: TLS 1.2 or higher.
• At rest: AES-256, performed by Clerke's hosting providers as part of their standard security posture.

Access controls

• User authentication: account access requires email verification and a password. Passwords are stored only as one-way hashes.
• Row-level data isolation: the database enforces row-level security at the engine level — a user's account only authorizes access to that user's own records. This is a database-enforced control, not just an application rule.
• No internal "god mode": Clerke personnel cannot read user reports without explicit user request, and any such access is logged.
• Service provider access: service providers handle data only to the extent needed for their function and under contractual confidentiality obligations.

Server-side validation

Files uploaded to Clerke are validated on Clerke's server before any processing or database recording happens:

• The file's actual contents are inspected to confirm it is a PDF (not just the extension or browser-reported MIME type).
• A maximum size is enforced server-side.
• The file is associated with the authenticated uploader; another user cannot claim ownership of an upload they did not make.
• A unique constraint prevents duplicate registrations of the same uploaded file.

Audit logging

Significant actions on user accounts are recorded to an append-only audit log. Each entry captures the user ID, action type, timestamp, IP address, and file metadata where relevant (filename, size — never file contents). Audit logs are retained for 12 months and then permanently deleted. Users can read their own audit log; access is enforced by the same row-level security used for the rest of their data.

Retention, deletion, and data portability

Retention by data category

• Source PDFs: automatically deleted shortly after report generation, in any case within 24 hours.
• Generated reports: retained on the user's behalf so they can be revisited. Users may delete any report at any time.
• Entity records: retained on the user's behalf. Users may delete any record at any time.
• Account data: retained while the account is active. Account deletion permanently removes account data, reports, and entity records (subject to audit log retention below).
• Audit logs: 12 months.
• Server access logs: approximately 30 days.
• Billing records: 7 years, per Canadian tax record-keeping rules.

Data portability — your right to export

You own your data; Clerke holds it on your behalf. You may export at any time:

• Generated reports, generated documents, and uploaded minute book documents can be downloaded individually in their original format.
• For a complete export of all entity data in machine-readable form, contact privacy@clerke.io and we will provide it within 30 days at no charge.

Cancellation and data deletion

When a user cancels their subscription:

• The account enters read-only mode for 30 days. The user can continue to access their data and download individual documents and reports during this window, and may request a complete data export at privacy@clerke.io.
• After 30 days, the user's account, reports, entity records, and personal information are permanently deleted from Clerke's primary systems.
• Audit logs and billing records are retained per the schedule above.

If Clerke ceases operations

• 90 days advance notice to all active users by email and on-platform notification.
• 90 days post-shutdown during which user data remains accessible for download. Users may request a complete data export at privacy@clerke.io during this window.
• After 180 days from the announcement, all customer data is permanently deleted.

AI provider arrangement

Clerke uses Anthropic (the maker of Claude) for AI processing. The contractual arrangement governing this use includes:

• Anthropic's Commercial Terms of Service, which prohibit Anthropic from using customer inputs or outputs to train models;
• A Data Processing Addendum governing how Anthropic handles personal information processed on Clerke's behalf;
• A Zero Data Retention addendum (pursued; status available on request) which, where in effect, further limits retention of inputs and outputs on Anthropic's systems;
• Server-side-only API access — Clerke calls Anthropic's API from its own infrastructure, never from the user's browser.

Network and operational security

• Clerke is hosted on infrastructure with established security practices (Supabase, Vercel, Stripe, AWS). See Subprocessor List.
• Hosting providers' standard monitoring is in use. Clerke maintains its own audit log on top.
• Clerke's payment flow uses Stripe's hosted checkout. Card numbers are not seen, transmitted, or stored by Clerke; Stripe holds payment data under PCI-DSS Level 1 compliance.

Breach response

If Clerke becomes aware of a security incident affecting personal information that creates a real risk of significant harm:

• Affected systems will be isolated promptly.
• The scope and impact will be assessed.
• Affected users will be notified within 72 hours.
• The Office of the Privacy Commissioner of Canada will be notified as required by PIPEDA.
• A written record of the incident and the response will be retained.

What Clerke deliberately does NOT do

• Clerke does not sell user data — ever.
• Clerke does not use minute book content to train AI models, and contractually prohibits its AI provider from doing so.
• Clerke does not run analytics, tracking pixels, or marketing scripts on its website.
• Clerke does not use third-party cookies. The only cookies set are first-party authentication cookies.
• Clerke does not store credit card numbers.
• Clerke does not retain source PDFs beyond the analysis window.
• Clerke does not access user reports without an explicit user request, and any such access is logged.

For firm administrators

Clerke is designed to support the cloud-service due diligence obligations BC lawyers undertake under Law Society guidance:

• Provider due diligence: this document, the Privacy Policy, and the Subprocessor List together describe Clerke's data handling. Additional documentation is available on request.
• Written agreement: firms requiring a Data Processing Agreement may request one.
• Knowledge of storage location: all primary customer data is hosted in Canada.
• Breach notification: incident notification protocols are above.
• Data retrieval and deletion: users can retrieve their reports and request deletion at any time.

For DPA requests, security questionnaires, or further questions:

Email: privacy@clerke.io