Information Security

This policy covers our access controls, device and credential management, backup posture, sub-processor arrangements, and the architecture we use to apply Claude to client analytics work.

1. Overview

Security underpins every client relationship and every system we run. We take a security-first approach to client data, built on three principles.

• Least-privilege access. People and systems are granted only the access they need, scoped to a single client at a time.
• Client-owned infrastructure. Each client’s analytical data lives in a Google Cloud project the client can audit, restrict, or revoke at any time.
• Technical controls over behavioural ones. Wherever possible, separation between clients is enforced by IAM policy rather than by analyst discipline.

2. AI and client data architecture

How Claude is used

Claude performs strategic analysis on client marketing and customer data, diagnosing conversion constraints, building CRO audits, producing paid media strategies, and generating monthly performance reports.

The data flowing through Claude varies by source. Modelled analytical data drawn from BigQuery is aggregated and business-ready. Marketing-platform connectors (GA4, Search Console, Google Ads, Meta) return aggregated platform reporting at the campaign, ad-group, property, query, or page level. These connectors do not return user-level or individual records. Anthropic’s API is the processing layer in both cases. Claude’s file outputs are saved by the analyst to Google Workspace.

Anthropic does not use API data to train its models. Anthropic’s Data Processing Addendum with Standard Contractual Clauses is incorporated into the Commercial Terms of Service that Data Story operates under, and is available at anthropic.com/legal/data-processing-addendum.

BigQuery analytics: read-only, per-client isolation

Each client’s analytical data lives in its own dedicated Google Cloud project. The region is selected per client based on data residency requirements and proximity to the client (default: australia-southeast1, Sydney). Claude accesses each project through a BigQuery MCP server authenticated with a dedicated per-client service account.

This account is read-only and scoped to the client’s marts dataset alone. It holds only BigQuery Data Viewer and BigQuery Metadata Viewer, on that dataset.

It cannot write, cannot read raw or intermediate datasets, cannot reach any other client’s project, and holds no Data Editor, Job User, IAM, owner, editor, or billing grants. Cross-client isolation is enforced by Google Cloud IAM and verifiable from the client’s side via the project’s IAM policy. It does not depend on analyst discipline.

Derived-table writes (materialising marts and reusable views) are performed by a separate non-interactive build identity used only by the scheduled data pipeline, never by an interactive Claude session. All read and write operations are captured in BigQuery audit logs and Cloud Audit Logs, reviewable by the client’s Google Cloud admins at any time.

Marketing-platform data access and campaign builds

Beyond modelled data in BigQuery, the AI system reads live marketing-platform data, and on Google Ads and Meta, builds campaigns, through dedicated MCP servers running on the analyst’s workstation. Read and write scopes are configured separately per platform.

Read-only platforms

• Google Analytics 4. Read-only MCP using the analytics.readonly scope, authenticated with the Application Default Credentials of a shared Data Story analytics identity. Each client grants that identity access to their own GA4 property; the credential cannot modify analytics configuration.
• Google Search Console. MCP scoped to webmasters.readonly, via a Google Cloud service account that impersonates the shared Workspace identity by domain-wide delegation. The OAuth scope enforces read-only access; the MCP also includes two sitemap-write tools, which the read-only scope refuses to authorise.

Read and write platforms (campaign builds)

• Google Ads. Claude uses the Google Ads API to read performance data and to build campaigns (Search, Performance Max, Display). Authenticated under Data Story’s authorised access to the client’s Google Ads account, scoped per client.
• Meta Ads. Claude uses the Meta Marketing API to read performance data and to build campaigns. Authenticated via a Business Manager system-user token scoped per client by ad-account.

All campaigns the AI builds are created in a paused or draft state. Activation is performed manually by a Data Story analyst. The AI workflow never sets a campaign live.

Mandatory pre-publish review

Before any campaign is published, a Data Story analyst opens it in the platform’s native tooling (Google Ads UI or Meta Ads Manager) and runs a pre-publish audit covering account access, asset rights, audience scope, budgets, and tracking. The analyst then activates the campaign manually. This control means that even if Claude were prompted to build something inappropriate, no campaign reaches a live audience without explicit human review.

Identity and separation model for this layer

Separation at this layer is enforced by each platform’s per-property or per-account access grant to the Data Story identity, plus the per-client MCP configuration loaded at session start. This is operational separation, distinct from the IAM-enforced isolation in the BigQuery layer.

The platform-connector model applies to every client engagement. Where a client also has a per-client BigQuery project, the IAM-enforced model described above applies on top, for the modelled analytical dataset. Reads and builds on ad platforms are attributable to Data Story’s authorised access to each client’s ad account.

3. Sub-processors

Data Story relies on a small number of vetted sub-processors. The principal sub-processors that handle or transmit client data are listed below.

Any new sub-processor that would handle client data is evaluated against the standards in this policy before being adopted. Subcontractors must meet or exceed Data Story’s security standards.

4. Access and identity

Password management

• All credentials are stored in LastPass.
• No browser or device password storage is permitted.
• Credentials are never stored in Google, email, messaging tools, or personal password managers.

LastPass security

• MFA is required for all access. Biometric hardware MFA keys, with fingerprint authentication, are provided to and used by all team members.
• Hardware MFA is required for administrative access.
• Master passwords are not stored digitally.

Multi-factor authentication

• MFA is enforced for all Google Workspace users and all LastPass users.
• Biometric hardware MFA keys are required for all Super Admin accounts.

Administrative and shared accounts

• Separate admin accounts are maintained for Google Workspace and for LastPass.
• Admin accounts are not used for daily work.
• Admin accounts are restricted to authorised individuals only.
• Shared accounts are used for tool access only, and carry no admin privileges and no recovery role.

Credentials, tokens, and keys

Credentials used to access client systems (OAuth tokens, service-account keys, API keys, platform tokens) live in protected workstation-local stores: the per-user MCP registry, the operating-system keychain, and Google Application Default Credentials. Master copies of shared secrets and credentials requiring rotation are held in LastPass under per-user or shared client vaults, MFA enforced. None are committed to source control. None are pasted directly into Claude or into working documents, emails, or chat messages.

Service-account keys and platform tokens are rotated on team-member off-boarding, on suspected exposure, at the cadence required by the issuing platform, and as part of the six-monthly security review.

OAuth tokens carry the minimum permission scope required for each integration. Each platform’s MFA enforcement applies on re-authentication. Anthropic API access is per-user and revoked on off-boarding.

Access to Google Cloud and Google Workspace is granted per-individual. Each team member has their own IAM grant on Data Story’s workspace service account and authenticates via short-lived (1-hour) impersonation tokens, not via a shared static key. If a device is lost or stolen, or a team member leaves, that individual’s IAM grant is revoked immediately at the project level, cutting off their access without delay. Any token already in flight expires within the hour.

5. Device security

Each laptop is hardened by default, with encryption, auto-lock, and authentication on every unlock. Device fleet management runs through Google Workspace endpoint management. FileVault status, auto-lock, and authentication settings are configured centrally and verifiable through the Workspace Admin console.

FileVault encryption

Full-disk encryption is required on every laptop and enforced via endpoint management. Drives are unreadable if a device is lost or stolen.

Auto-lock

Screens auto-lock within 30 minutes of inactivity, removing the unattended-device exposure window.

Authentication

Password or biometric protection is required to unlock. No anonymous or guest access to a work device.

6. Backup and data protection

Workspace data is backed up to a third-party vault with tightly restricted access and enforced MFA. Google Workspace data (Drive, Mail, Calendar) is backed up daily via Spanning Backup by Kaseya.

Backup console access is restricted to Super Admin accounts, with no analyst or standard-user access, and backup sign-in is gated by MFA through Google Workspace identity. Single-factor compromise is insufficient.

7. Physical security

Our Queenstown office is secured by surveillance and after-hours lock-up. Security cameras are in operation at all times across the working environment. Premises are locked and secured outside business hours, and no client-data hardware leaves the office unattended.

8. Ongoing security review

A formal security review is conducted across five areas.

9. Privacy and data protection

Both parties must comply with the Privacy Act 2020. You remain the data controller of any personal information we handle on your behalf; we act solely as processor, on your instructions.

If we receive an individual access or correction request, or a privacy complaint relating to your data, we will notify you promptly and assist your response.

If we become aware of a security incident we will notify you as soon as reasonably practicable and assist with investigation and remediation. We will not notify regulators or affected individuals about your personal information without your prior approval; that decision and responsibility rests with you. Each party bears its own costs arising from a security incident, subject to our terms and conditions.

10. Data processing and legal references

Data Story’s standard Terms of Engagement contain data protection provisions covering retention, deletion on termination, sub-processor disclosure, and other client data obligations. Our Privacy Policy covers personal information collected outside a client engagement.