The path your data travels, and the paperwork that permits it.

Multi-factor authentication on client systems

Every team member connecting to a client's accounting software, bank feed, or shared storage does so behind multi-factor authentication. Single-factor password access to client systems is not permitted under our internal access policy, regardless of role or tenure.

Evidence: policy document

Least-privilege access control

Team members are granted access only to the specific client files and systems their engagement requires, not blanket access across the client base. Access is reviewed when an engagement ends or a role changes, and removed promptly rather than left open.

Evidence: policy document

No local storage of client files

Client accounting data is worked on inside the client's own software (QuickBooks Online, Xero, or similar) or an approved shared workspace, not downloaded and saved to an individual team member's laptop or personal device. This limits how many places a client's financial data can end up.

Evidence: policy document

Signed non-disclosure agreement for every staff member

Every team member with any access to client financial information signs a non-disclosure agreement before their first day on an engagement, covering client data specifically, not just general company confidentiality. This is a condition of employment, not an optional add-on for larger accounts.

Evidence: policy document

Full-disk encryption on team devices

Laptops used to access client accounting systems run full-disk encryption, so a lost or stolen device does not expose readable client data. This is a baseline device requirement before any team member is granted client system access, not a later hardening step.

Evidence: policy document

Documented onboarding and offboarding for client access

Every engagement follows a written checklist for granting access when a team member joins a client's books and revoking it when they leave the engagement or the company. This removes the common failure mode where a departed team member's access to a client's accounting software is simply forgotten.

Evidence: policy document

Written information security program (WISP)

A written information security program aligned to IRS Publication 4557, covering administrative, technical, and physical safeguards for taxpayer and client financial data, is being drafted ahead of handling any US tax preparation data. A summary will be published once it is adopted, and no US tax data will be processed before it is in place.

Data processing agreement templates with SCCs and IDTA

Standard Contractual Clauses for EU client data and a UK International Data Transfer Agreement, each paired with a transfer risk assessment, are being finalized with counsel to cover the cross-border transfer of client financial data from the UK and EU. These will be signed as part of onboarding for clients in those regions.

Section 7216 consent workflow for US tax data

A written-consent workflow meeting the format required by Revenue Procedure 2013-14 is being built so that every US client explicitly consents, before any tax return information is disclosed, to that information being used and processed by our team. No US taxpayer data will be shared ahead of a signed consent.

Errors and omissions insurance

A professional errors and omissions policy covering the firm's advisory and preparation-support work is in the process of being placed. We will not claim coverage is in force, or name a policy, until it is confirmed bound and the certificate is on file.

Cyber liability insurance

A cyber liability policy covering data breach response for client financial data is in the process of being placed alongside our errors and omissions coverage. As with that policy, we will not claim coverage exists until it is confirmed bound.

Third-party software vendor review

A documented review of the security posture of every software vendor in our stack, QuickBooks Online, Xero, and connected apps, is being formalized into a standing checklist run before any new tool is adopted for client work, rather than left to individual judgment.

Written incident response plan

A documented, tested procedure for detecting, containing, and notifying clients of a security incident involving their data is being drafted alongside the written information security program. It will define notification timelines and responsibilities before it is relied on rather than after an incident occurs.

SOC 2 Type I examination

We intend to engage an independent auditor for a SOC 2 Type I examination once the underlying controls above (WISP, incident response, vendor review, access management) are fully in place and operating, since a Type I report only has value once there is something real for the auditor to examine. No SOC 2 report exists today, and we will not use that language about ourselves until one is issued.

ISO 27001 certification

ISO 27001 certification is a longer-term goal, particularly for UK and Australian clients where it carries more procurement weight, and would follow after SOC 2 readiness work is complete. No certification exists today and none is implied by any control listed above until it is actually issued.

Independent penetration test

An independent, third-party penetration test of client-facing systems and internal tooling is planned as part of SOC 2 readiness work, to validate the access and encryption controls above rather than take them on faith. No test has been performed as of today, and none is claimed.