Security you
can check.

Our security posture

Tonic is a specialist agency, not a software company. Our security model reflects that honestly: we keep our own attack surface deliberately small, we store nothing of value on local machines, and we build on cloud platforms whose security is independently audited at a scale no agency could replicate.

Three principles run through every policy in this suite:

1. Cloud-native by default

All business and client data lives in approved cloud platforms, principally Google Workspace and Basecamp. Primary client and employee data is not stored on workstations, and the use of portable media such as USB drives for sensitive data is prohibited. This removes an entire category of risk: lost drives, unencrypted laptops full of client work, and orphaned local copies that nobody remembers to delete.

2. Inherited assurance, verified annually

Where we rely on a provider’s controls, we say so, and we check. Our Information Security Officer reviews the current ISO 27001 certificates and SOC 2 reports of every critical vendor each year and records the outcome. Inheriting a control is not the same as ignoring it.

3. Proportionate, documented, and owned

Every policy has a named owner, an executive approver, an effective date and an annual review cycle. Controls are sized to a business of our scale rather than copied from an enterprise template, but each one is written down, approved and auditable.

Governance & accountability

Security at Tonic is owned by named roles with executive backing, not distributed vaguely across the business.

Information Security Officer (ISO)

Owns the policy suite. Responsible for access provisioning and review, vendor security assessment, endpoint and patch management, code review sign-off, and leading the technical response to any incident.

Data Protection Officer (DPO)

Owns data protection compliance under UK GDPR: retention schedules, the data inventory, breach risk assessment, and all contact with the Information Commissioner’s Office.

Chief Client Officer / Managing Director

Provides executive oversight, approves the foundational policies, and is the final approver for every external communication during an incident.

All personnel

Required to complete security training, formally acknowledge the policies, store data only in approved systems, and report any suspected incident immediately.

Review cycle

The full suite was formally reviewed and adopted on 8 October 2025 (version 1.1). Every document carries an annual review cycle, with the next scheduled review on 8 October 2026. Policies are also re-reviewed out of cycle after any significant change to our technology, legal obligations or business operations, and after any significant incident. All changes are version-controlled and logged.

Certifications & registrations

ICO registration

Tonic is registered with the UK Information Commissioner’s Office as a data protection fee payer under the Data Protection Act 2018, and maintains that registration on an ongoing basis.

ICO registration is a statutory requirement for organisations processing personal data. It confirms we are on the public register and pay the annual fee. It is not a security certification, and we describe it as exactly what it is.

Inherited certifications

The platforms that hold Tonic’s data are independently audited. Our Information Security Officer reviews the current certificates and audit reports annually and records the review.

Copies of the underlying certificates and SOC 2 Type II reports are held in our internal vendor risk records and can be discussed with clients under NDA.

Data protection & privacy

Tonic Agency Limited processes personal data in accordance with the UK GDPR and the Data Protection Act 2018. Depending on the engagement we may act as a data controller (deciding how and why data is used, for example our own recruitment and business operations) or as a data processor (acting only on a client’s documented instructions within a project).

Lawful bases

Each processing purpose is mapped to a lawful basis. Client communication and project delivery rest on performance of a contract; finance and employment records on legal obligation; recruitment and business administration on legitimate interests; marketing on consent or legitimate interests. Where we rely on legitimate interests, we balance the business purpose against the rights of the individual and record that assessment.

Individual rights

Individuals have the right to access, correct, delete, restrict or object to processing of their personal data, to request portability, and to withdraw consent at any time. Requests are handled by our Data Protection Contact (see Contact); we may require identity verification before responding. Anyone who is unhappy with how we have handled a request can complain to the ICO, though we would ask to hear from you first.

Sharing and international transfers

We do not sell personal data. Data is shared only with the people and organisations needed to deliver the work: personnel assigned to the project, the client where delivery requires it, our cloud providers, professional advisers, and regulators or law enforcement where legally mandated. Where a supplier processes data outside the UK, we rely on adequacy regulations, standard contractual clauses, or the data processing terms of established cloud providers.

Children’s data and automated decisions

Our services are aimed at business clients. We do not knowingly collect children’s data except where a client project specifically requires it under lawful instruction and strict safeguards. We do not use personal data for automated decision-making that produces legal or similarly significant effects on individuals.

What data we hold

We maintain a data inventory that maps every significant category of personal data to the system that holds it, the purpose, and the lawful basis. It is reviewed annually.

How data moves

The flow is deliberately simple. Data enters via secure email or is created directly in Basecamp. It is processed and stored only within Google Workspace or Basecamp. There is no local storage of primary client or employee data on workstations. It is encrypted at rest and in transit by the providers. Internal access is role-based and requires MFA. Nothing is shared externally without client consent, a contractual requirement, or a legal obligation.

Classification & acceptable use

Information is classified as Public, Internal, Confidential or Highly Confidential, and is labelled and handled according to that classification wherever it is stored. Confidential and Highly Confidential information must be encrypted in transit and at rest.

Company systems are for legitimate business purposes only. Credentials must never be shared: not with colleagues, not with clients, and not with anyone claiming to be IT support. Business data must be stored exclusively in approved systems; storing sensitive data on personal devices, local drives or unapproved services is prohibited. Any suspected incident must be reported immediately.

Non-compliance is a disciplinary matter, up to and including termination of employment or contract. The Information Security Officer audits compliance.

Encryption

All company and client data is encrypted at rest with AES-256 and in transit with TLS 1.2 or higher. This applies to data in Google Workspace and Basecamp, and to traffic to our web properties. Company-issued laptops use full-disk encryption.

Key management

Tonic does not generate, store, rotate or destroy cryptographic keys. Key management is handled entirely by our cloud providers through their own managed key services, protected by infrastructure that is subject to independent third-party audit. Cryptographic keys are never accessible to Tonic personnel; access to encrypted data is controlled solely through user authentication and authorisation.

The Information Security Officer verifies these controls annually by reviewing the providers’ published security documentation and current SOC 2 and ISO 27001 reports. Any suspected compromise of data confidentiality is handled under our incident response procedure, coordinated with the provider where necessary.

Retention & secure deletion

We keep personal data only as long as it is needed for its purpose or required by law. These are our default periods; client contracts or legal requirements may override them.

Archiving and destruction

Data that must be kept for legal or contractual reasons but is no longer in active use is moved to secure, access-controlled cloud storage. At the end of its retention period, data is securely and irreversibly deleted using the platforms’ native cryptographic deletion processes. The Information Security Officer is responsible for ensuring automated retention rules are correctly configured, or that manual deletion has been performed and verified.

Media sanitisation

When a device reaches end of life or an employee departs, hardware is returned to the Information Security Officer and subjected to full cryptographic erasure or a multi-pass secure wipe before it can be redeployed or disposed of. Every sanitisation event is logged against the device serial number with the date and method used. Devices sent for disposal go to a certified e-waste vendor and a certificate of destruction is obtained. Portable storage media are not used for sensitive data at all.

Access control

Access is granted on the principle of least privilege: the minimum permissions needed for a role, and nothing more.

• Unique identities. Every user has their own account. Shared or generic accounts are prohibited unless technically unavoidable and formally approved.
• Privileged access is tightly held. Administrator roles are restricted to the Information Security Officer and are used only for administrative work, never for day-to-day activity.
• Formal provisioning. Access is requested by the line manager and approved by the Information Security Officer before it is granted.
• Quarterly review. All user access rights are formally reviewed every quarter to confirm they still match each person’s role. Changes are logged.
• Rapid revocation. HR notifies the Information Security Officer immediately on any departure. All access is revoked within 24 hours, and instantly in the case of an immediate termination.
• Project-scoped permissions. Basecamp permissions are granted per project and withdrawn as soon as they are no longer needed.

Logging and monitoring

User and administrative activity in core systems is logged. Logs are retained for a minimum of 12 months, reviewed regularly, and examined in detail in response to any suspected incident.

Authentication

Multi-factor authentication is mandatory for all users on every system that supports it, including Google Workspace and Basecamp. The preferred second factor is a hardware security key or an authenticator app.

Password requirements are enforced centrally through our identity provider: a minimum of 12 characters combining upper and lower case letters, numbers and special characters, and passwords that are unique to Tonic and not reused on personal or external services. Passwords must never be shared, and must not be kept in plain text files, spreadsheets or email. A secure password manager is the expected tool. Where Tonic operates an application that stores passwords, they are salted and hashed with a strong modern algorithm.

Accounts lock automatically after repeated failed sign-in attempts and can only be released by the Information Security Officer. Self-service password reset requires verification via MFA, and every reset is logged. Anyone who suspects their credentials have been compromised must change them immediately and report it.

Backup & resilience

Tonic operates a cloud-native backup strategy. We hold no physical backup media: no tapes, no external drives, no offsite media rotation, and therefore none of the risks that come with them.

• Google Workspace data is protected by Google’s native, real-time, geographically redundant backup, continuously replicated across multiple data centres.
• Basecamp project data is backed up automatically by Basecamp’s own redundant cloud infrastructure.
• Creative assets on local machines are synced continuously to Google Drive, so a lost or failed laptop costs time, not data.

Backups inherit the same controls as production data: AES-256 encryption at rest, TLS in transit, and access to restoration functions restricted to the Information Security Officer. Minimum recoverable retention is 90 days.

Restoration testing

A backup you have never restored is a hypothesis, not a control. The Information Security Officer runs and documents a quarterly file-level restoration test: selecting a recently modified or deleted item, restoring it through the platform’s administrative tooling, and verifying the integrity and accessibility of the result. Each test is logged with the date, the item restored and the outcome.

Geographic redundancy

Our providers automatically replicate data across multiple, physically separate data centres, giving us protection against localised events such as fire, flood or power failure without any manual intervention on our part. The physical security of those facilities is covered under Physical security.

Business continuity

Our Business Continuity and Disaster Recovery Plan defines how we keep working through a disruption and how quickly we expect to recover.

Business impact

Disruption to our core cloud services is our highest-impact scenario, mitigated by those providers’ enterprise-grade resilience. Loss of an individual workstation is moderate impact, mitigated by continuous cloud syncing. A physical office outage is low impact, because Tonic is fully capable of operating remotely.

Activation and testing

The plan is activated when a critical system is unavailable beyond its recovery time objective or significant data loss is confirmed. The Information Security Officer leads recovery and internal communications, using alternate channels if primary systems are down; the CCO approves all client communications. Recovery procedures are verified quarterly, and an annual tabletop exercise walks key personnel through a simulated scenario. Results are documented and any gaps tracked to remediation.

Vulnerability management

We identify vulnerabilities through three layers:

• Cloud platforms. We rely on the continuous vulnerability management programmes of Google and Basecamp, verified annually through their SOC 2 and ISO 27001 reports.
• Application code. Automated dependency scanning runs continuously in our source repositories, checking third-party libraries against known vulnerability databases and alerting the Information Security Officer to anything critical.
• Endpoints. Every company laptop runs centrally managed, modern anti-malware with continuous scanning and device health reporting.

Patch schedule

Security patches are applied to systems under our direct control on a severity-based schedule:

For core cloud platforms we rely on the providers’ own patching schedules, which are reviewed as part of vendor risk management. All identified vulnerabilities are tracked in an internal risk register with an assigned owner and a remediation deadline set by severity. The Information Security Officer reports on vulnerability status to management quarterly.

Penetration testing

Our testing strategy is risk-based and layered to match where the risk actually sits.

Layer 1: Core infrastructure

For Google Workspace and Basecamp we rely on the extensive, continuous penetration testing carried out by the vendors themselves, verified annually through their SOC 2 and ISO 27001 reports.

Layer 2: Client applications

For websites and applications we build for clients, penetration tests can be commissioned as part of the project scope at the client’s request. Results go directly to the client and findings are remediated before launch.

Layer 3: Tonic’s own environment

Tonic commits to a formal penetration test of its own internal environment annually, and after any significant change. A summary of high-risk findings and their remediation status is available to clients on request under NDA.

Findings from any test are logged in our risk register with a severity rating and remediated to the timelines set out under Vulnerability management.

Secure development

Everything Tonic builds, from client websites to web applications to internal tools, is developed under a documented set of security practices.

• OWASP-aligned coding. Development follows secure coding practices aligned to the OWASP Top 10.
• No hardcoded secrets. API keys and credentials are never committed to source code. They are held in a managed secrets store or the secure environment-variable facilities of our hosting platforms.
• Trusted dependencies. Only well-maintained, reputable libraries are used, and they are continuously scanned for known vulnerabilities. Critical and high-severity findings must be resolved before deployment.
• Mandatory review. Every change is reviewed against a security checklist covering secrets, dependency scan results, input validation, and error handling that does not leak sensitive information. It is then signed off by the Information Security Officer or a designated senior technical lead before it can be merged and deployed.
• Controlled deployment. Production deployments come only from the reviewed main branch, through audited platforms. Manual changes directly to production are prohibited.
• Secure hosting. Applications are deployed to reputable cloud platforms providing DDoS protection, managed firewalls and managed TLS certificates as standard.
• Annual training. Developers complete annual secure coding training covering the OWASP Top 10.

AI governance & responsible use

Tonic uses AI in the course of delivery and builds AI-enabled systems for clients. Both are governed, and neither is treated as an exception to the controls set out elsewhere on this page.

How we use AI in delivery

AI-assisted development is part of how we work. Every AI-assisted change is reviewed by a named engineer and passes the same tests, security gates and peer review as any other change; generation is never a route around review. Client material is not pasted into consumer AI tools. Only approved enterprise services with contractual no-training terms are used, and they are assessed under Third-party risk like any other subprocessor.

Client data and model training

Client data is not used to train third-party foundation models. Enterprise API terms carry contractual no-training commitments, and where a client’s data policy requires stronger assurance than a contractual term, systems can be built against models hosted inside the client’s own environment so that data never reaches a third party at all.

Human accountability

AI does not publish, decide or act on its own. In the systems we build, AI-generated content is created as a draft and requires named human approval before it is published, and AI is given access only through defined operations that reject anything outside their contract. Consistent with our position under Data protection & privacy, we do not build systems that make automated decisions producing legal or similarly significant effects on individuals without human involvement.

AI in regulated contexts

Some uses of AI carry specific legal obligations. Under the EU AI Act, systems used in employment and recruitment are listed in Annex III as high risk, and UK GDPR Article 22 restricts solely automated decisions with legal or similarly significant effects. Classification of a given system is a determination for the client as provider or deployer, working with their own legal counsel; our role is to design so that exposure is reduced where possible and to produce the supporting evidence either way.

In practice that means we keep AI advisory and human-supervised rather than determinative, and we maintain the artefacts a regulated assessment would call for: a documented risk classification, a record of the data used and its governance, technical documentation of the system, event logging sufficient to reconstruct what happened, clear notice to the people affected, a defined point of human oversight, and testing evidence for accuracy and robustness. Where a system involves systematic profiling of individuals we support the client in completing a Data Protection Impact Assessment before launch.

Model providers and hosting

Foundation-model providers are treated as subprocessors and reviewed accordingly. Model access is arranged in one of three ways depending on how sensitive the data is: through a governed enterprise API, through the equivalent service running inside the client’s own cloud tenancy, or through open-weight models hosted on infrastructure the client controls. The architecture keeps providers behind a stable interface so a change of model or provider does not require the system to be rebuilt.

Testing AI features

Conventional application testing does not exercise the ways AI systems fail. In addition to the testing described under Penetration testing, AI features are tested for prompt injection from user input, uploaded documents and retrieved content, for attempts to reach data the requester is not entitled to, and for resistance to instructions intended to bypass their operating rules. Findings are remediated to the timelines under Vulnerability management.

People security

Security is built into the employment lifecycle from before day one to after the last day.

Before joining

All candidates undergo background screening appropriate to the role, including right-to-work verification and reference checks, before a formal offer is made. Every offer is conditional on signing a confidentiality and non-disclosure agreement.

Onboarding

HR formally notifies the Information Security Officer of each new starter’s role and start date. Accounts are created on the principle of least privilege. Mandatory security awareness and data protection training is completed on day one, and access to sensitive client data is withheld until that training is logged as complete. New personnel formally acknowledge the security policies.

During employment

Any change of role that affects access rights must be communicated by HR to the Information Security Officer, who adjusts permissions and logs the change. Everyone completes an annual security refresher.

Leaving

HR notifies the Information Security Officer immediately on resignation or termination. System access is disabled at the end of the final working day, or instantly in the case of an immediate termination. All company property, including laptops, mobile devices and access cards, is returned and checked off against an asset list, and devices are securely wiped before reuse or disposal.

Awareness & training

Security awareness training is mandatory for all employees, contractors and freelancers during their first week, with a refresher every year. The curriculum covers:

• Information security fundamentals: confidentiality, integrity and availability
• Phishing and social engineering: how to spot it and how to report it
• Password and authentication security, including mandatory MFA
• Data handling: classifying data correctly and protecting confidential client information
• Secure remote working
• Incident reporting: why speed matters more than certainty

The Information Security Officer maintains a training register recording who completed what and when, and issues ad-hoc bulletins in response to emerging threats. Failure to complete required training can result in system access being suspended until it is done. The programme itself is reviewed and updated annually.

Remote & device security

Tonic works remotely as standard, so remote working is treated as the default security case rather than an exception.

• Company devices only. Remote work is carried out on company-issued, managed laptops configured with full-disk encryption, managed anti-malware and timely security patching. Storing or processing company or client data on personal computers, tablets or phones is prohibited.
• Cloud-only storage. Work is saved to approved cloud systems, not local drives.
• Trusted networks. Remote work must be conducted over a secure network protected by a strong WPA2/WPA3 password. Connecting to Tonic systems from public or untrusted networks is prohibited unless routed through an approved VPN.
• Automatic screen lock is enforced on all devices after a short period of inactivity.
• Physical care. Devices must be stored securely and never left unattended in public. Loss or theft must be reported immediately.
• Visual confidentiality. Personnel are responsible for ensuring sensitive information on screen cannot be seen by others. Printing confidential material should be avoided; where unavoidable, it is shredded immediately after use.

Physical security

Data centres

The overwhelming majority of Tonic’s data sits in cloud data centres operated by our providers, whose physical controls are independently audited under ISO 27001 and SOC 2. Those controls include 24/7 on-site security and perimeter defences, biometric and multi-factor entry control, comprehensive CCTV and intrusion detection, and redundant power, cooling and fire suppression. The Information Security Officer verifies these annually.

Tonic’s office

Office access is restricted to authorised personnel using unique credentials, issued, revoked and reviewed quarterly by the Information Security Officer, and revoked for departing staff on their last day. Visitors sign in, are issued a pass and are escorted at all times. Sensitive documents are kept in locked cabinets, the premises are protected by a monitored alarm system, and devices left overnight are secured. A clear desk and clear screen rule applies: screens are locked when unattended and confidential papers are never left out.

Third-party risk

Our security is only as good as the security of the platforms we put data into, so vendors are assessed before use and reviewed every year after.

Before onboarding a vendor

1. Risk classification based on the sensitivity of the data the vendor will handle.
2. Security review for anyone handling sensitive data, verifying industry certifications such as ISO 27001 and SOC 2.
3. Contractual requirements covering confidentiality, data protection compliance and immediate notification of any security breach.
4. Formal approval by the Information Security Officer, recorded in our vendor risk records, before the service is used.

Ongoing

We maintain a vendor risk register tracking every approved vendor, its risk rating and the date of its last review. All vendors are reviewed at least annually. Google Workspace and Basecamp are designated critical partners and receive a documented annual review of their current SOC 2 and ISO 27001 reports. Employees may only use approved third-party services for company business.

Offboarding

When a vendor relationship ends, the Information Security Officer ensures all access is revoked and that Tonic data is securely returned or destroyed in line with the contract.

Client exit & handover

A client should be able to leave without the work becoming hostage to the relationship. We build so that leaving is straightforward, and we would rather say how that works before an engagement than be asked at the end of one.

What the client owns

Source code, content, data and infrastructure definitions belong to the client. We do not retain a proprietary runtime, a licensed component the client cannot operate without us, or a hosting arrangement that only we can administer. Where a project uses open-source foundations, we favour permissive licences so ownership is real rather than conditional.

At the end of an engagement

Handover covers repositories, credentials and secrets, environment and infrastructure configuration, and the runbooks needed to operate and recover the system. Documentation is maintained during delivery rather than assembled at the end, so what is handed over reflects what was actually built. A transition assistance period is agreed in the contract, and our access to client systems is revoked on completion in line with Access control.

Continuity of the team

We deliberately work in small senior teams, which makes continuity a fair question to ask. Each critical role has a named deputy, work on critical paths is paired rather than owned by one person, and architectural decisions are recorded in written documentation rather than held in individual heads. The test we hold ourselves to is whether someone new could pick up the system from what is written down.

If Tonic ceased to trade

Because clients hold their own code, content and infrastructure, and because we do not operate a proprietary platform that systems depend on, a client’s system continues to run if we are no longer here. Source code escrow can be arranged where a client requires it, though for self-hosted builds the client already holds everything escrow would release.

Incident response

A security incident is any event threatening the confidentiality, integrity or availability of Tonic’s systems or data, from an accidental disclosure to a deliberate attack, including malware, unauthorised access and lost or stolen devices.

How we respond

1. Report. Any employee who suspects an incident reports it immediately to the Incident Response Lead (the Information Security Officer), stating what was seen, when, and which systems are affected. Reporting a suspicion is always the right call; failing to report is a disciplinary matter.
2. Triage within one hour. The Incident Response Lead assesses the report and classifies severity as Low, Medium or High. If client or personal data may be involved, the Data Protection Officer is engaged immediately.
3. Contain. Immediate containment (disabling an account, isolating a device, revoking permissions) while preserving evidence such as logs and screenshots.
4. Investigate and resolve. Root cause and full scope are established, the threat neutralised, and affected systems securely restored.
5. Communicate. The Incident Response Lead keeps the CCO and relevant staff informed. All client and regulatory notification runs through our breach notification procedure, and every external message is approved by the CCO before it is sent.
6. Review. For any high-severity incident, a post-incident review is held within five working days of resolution to identify lessons learned and implement corrective actions.

Every incident, action and outcome is recorded in our incident register and retained for a minimum of three years. The procedure is tested annually through a tabletop exercise, and reviewed after any significant incident.

Breach notification

Where an incident involves personal data, a separate procedure runs alongside incident response, against the UK GDPR’s 72-hour regulatory clock.

The clock starts the moment the Data Protection Officer is notified, and the Information Security Officer must escalate to the DPO within one hour of confirming that personal data may be affected. The Data Protection Officer is the single point of contact for the ICO. Every action, decision and communication is recorded in our confidential breach register.

Policy register

The full suite below was formally reviewed and adopted at version 1.1, effective 8 October 2025, with a next review date of 8 October 2026. Each document has a designated owner and executive approver. Copies can be provided to clients on request, under NDA where appropriate.

Contact & disclosure

Security and data protection enquiries

Clients, candidates and members of the public can reach our Data Protection Contact at leantonio.nelson@tonic-agency.com for data subject rights requests, privacy questions, security questionnaires, or requests for policy documentation.

Reporting a vulnerability or incident

If you believe you have found a security vulnerability in a Tonic web property, or you suspect a security incident involving Tonic data, please contact us using the address above with enough detail to reproduce or verify the issue. We will acknowledge your report and keep you updated on our assessment. Please do not access, modify or delete data belonging to others, and give us reasonable time to investigate before disclosing publicly.

Complaints

If you are unhappy with how we have handled your personal data, please contact us first so we can put it right. You also have the right to lodge a complaint with the UK Information Commissioner’s Office.

Company details

Registered name

Tonic Agency Limited

Company number

08035962 (England & Wales)

Registered office

Level 5a Maple House, 149 Tottenham Court Road, London, W1T 7NF

Office

Runway East, 18–20 Crucifix Lane, London, SE1 3JW

ICO registration

ZC150873, data protection fee payer, expires 17 May 2027

This page summarises Tonic Agency Limited’s information security policy suite, version 1.1, effective 8 October 2025. It is a public summary and does not reproduce the internal policy documents in full. Where this page and the underlying policies differ, the policies take precedence.