Security & Data Handling

1. Our Approach

We design for least privilege, minimise the data we hold, and prefer boring, well-understood controls over novel ones. Security work is part of ordinary delivery — reviewed in the same pull requests as everything else — rather than a separate gate at the end.

2. Governance and Accountability

Security is owned at management level rather than delegated to whoever is nearest. A named member of our leadership is accountable for information security, for maintaining this statement, and for coordinating our response to any incident.

Data protection and security matters — including vulnerability reports — all reach us at office@c9group.dev.

We review this statement, our subprocessor list, and our access registers at least annually, and after any material change to our infrastructure.

3. What Data We Hold

Website visitors

Standard request telemetry — IP address, user agent, referrer, pages requested — plus analytics and advertising identifiers where you have consented to them. Details, including the lawful basis for each purpose, are in our Privacy Policy.

Prospective clients

What you send us through a contact form, a booking, or email: typically name, business email, company, and a description of your project. We ask for the minimum needed to have a useful first conversation, and we do not require personal data beyond that.

Client engagement data

During an engagement we may hold source code, architecture documentation, credentials for systems you ask us to work on, and — where the work requires it — data held in those systems. This category is governed by the engagement agreement and, where personal data is involved, by a Data Processing Agreement.

4. Hosting and Data Residency

This website runs on Amazon Web Services. Application compute and origin storage are hosted in the eu-central-1 (Frankfurt, Germany) region, inside the European Union. Static assets are distributed through Amazon CloudFront's global edge network, which caches public page content and assets — not form submissions or personal data — close to visitors.

Client project infrastructure is provisioned in the region the client specifies. Where a client requires EU-only data residency, we architect for it and confirm it in writing in the engagement agreement.

5. Encryption

• In transit: All traffic to and from this website is served over HTTPS with TLS 1.2 or higher. Plain HTTP requests are redirected to HTTPS.
• At rest: Data stored in our AWS environment is encrypted at rest using AWS-managed keys.
• Internal transfer: Traffic between our infrastructure components is encrypted in transit.
• Endpoints: Workstations used to access client systems and source code have full-disk encryption enabled.

6. Access Control

• Least privilege: Access is granted per role and per engagement, limited to what the work requires, and reviewed periodically.
• Multi-factor authentication: Required on our cloud provider consoles, source control, and email.
• No shared accounts: Every person authenticates as themselves, so actions are attributable.
• Credential handling: Secrets are held in a managed secret store or an encrypted vault. They are never committed to source control, sent over chat, or stored in plaintext files.
• Client credentials: Where you grant us access to your systems, we prefer named accounts scoped to our role over shared credentials, and we ask you to revoke them when the engagement ends. If you have not revoked ours, ask us — we will tell you exactly what access we still hold.
• Offboarding: Access is revoked when a person leaves the company or rolls off an engagement.

7. Secure Development

• Code review: Changes are reviewed by someone other than the author before merging.
• Version control: All work is tracked in Git, giving a complete and attributable change history.
• Automated testing and CI: Test and lint suites run automatically on every change; failures block the pipeline.
• Dependency management: Third-party dependencies are pinned via lockfiles and monitored for published vulnerabilities. Security advisories affecting a dependency we ship are triaged on receipt.
• Secret scanning: Repositories are monitored for committed credentials; anything detected is revoked and rotated rather than merely deleted from the history.
• Infrastructure as code: Environments are defined in versioned configuration and deployment scripts, so changes are reviewable and reproducible rather than applied by hand.
• Environment separation: Development, staging, and production are separated, with production credentials held only where production runs.

Our engineers use AI-assisted coding tools. All generated code goes through the same review, testing, and dependency checks as code written by hand, and we do not paste client credentials or confidential client data into third-party AI tools.

8. Vulnerability and Patch Management

We monitor security advisories for the platforms and dependencies we run. Patching targets, measured from the point a fix is available to us:

Where a fix is not yet available, we apply a compensating control — disabling the affected feature, restricting network access, or adding detection — and record the decision. Patching commitments for systems we operate on a client's behalf are set out in the applicable service agreement and may be stricter than the targets above.

9. Logging and Monitoring

Application and infrastructure logs are collected centrally in our cloud environment, retained for a defined period, and reviewed when investigating an error or a suspected incident. Administrative actions in our cloud accounts are recorded in an audit trail.

We deliberately keep logs free of unnecessary personal data, and we do not log request bodies containing credentials or form contents.

10. Backups and Continuity

This website is stateless and rebuildable from source: the deployable artefact is produced from version-controlled code, so recovery means redeploying rather than restoring. Source code is held in Git with distributed copies.

For client systems we operate, backup frequency, retention, recovery point objective, and recovery time objective are defined per engagement, and restores are tested rather than assumed to work.

11. Working With Client Data

• Data Processing Agreement: Where we process personal data on your behalf, we act as a processor under a written DPA meeting Article 28 GDPR. We provide our standard DPA on request, and we can review yours.
• Non-disclosure: We sign mutual NDAs on request, including before a first scoping conversation.
• Instruction-bound processing: We process client personal data only on documented instructions, and never for our own purposes.
• Subprocessor notice: We tell you before adding a subprocessor that would process your personal data, and give you the opportunity to object.
• Return and deletion: At the end of an engagement we return or delete client data on request, and confirm in writing once it is done.
• Assistance: We help you respond to data subject requests, security questionnaires, and regulator enquiries relating to systems we built or operate.

12. Personnel

• Everyone working on client engagements — employee or contractor — is bound by written confidentiality obligations that survive the end of their engagement.
• Subcontractors are held to security and confidentiality obligations no less protective than our own, and we remain responsible to you for their work.
• Access to a client environment is granted only to the people working on it, and removed when they roll off.
• Our team works across distributed locations; remote access to client systems follows the same authentication and least-privilege rules as office-based access.

13. Subprocessors and Third-Party Services

The following third parties may process data in connection with this website. Analytics and advertising services load only after you consent through our cookie banner; the rest are necessary to operate the site or to reply to you.

We implement Google Consent Mode, so Google tags load in a denied state and no analytics or advertising storage is written until you consent. Withdrawing consent through the cookie banner clears the advertising identifiers we hold locally.

Subprocessors used on a specific client engagement are listed in the DPA for that engagement, not here.

14. International Transfers

Website hosting keeps data in the EU. Some of the providers above are established outside the European Economic Area, principally in the United States, which means certain data may be transferred there.

For those transfers we rely on the European Commission's Standard Contractual Clauses, on the provider's certification under the EU–US Data Privacy Framework where applicable, and on the supplementary measures described on this page — chiefly encryption in transit and data minimisation. The transfer mechanism for each provider is available on request.

15. Incident Response

If we identify a security incident affecting data we hold, we contain it, assess its scope, remediate the cause, and notify those affected.

After any significant incident we carry out a blameless post-incident review, record the root cause and corrective actions, and share the findings with affected clients.

16. Responsible Disclosure

If you believe you have found a security vulnerability in this website or in any system we operate, we want to hear from you.

In return, we ask that you:

• Give us reasonable time to fix the issue before disclosing it publicly
• Avoid accessing, modifying, or deleting data that is not yours, and stop at the point you have demonstrated the vulnerability
• Do not run denial-of-service tests, send spam, or use social engineering or physical attacks against our staff or offices
• Do not use automated scanners that degrade service for other users

We do not currently run a paid bug bounty programme. We do read every report a person sends, and we say thank you.

17. Standards We Work To

Our practices are designed to align with the following frameworks. We are not currently certified against any of them, and we will state the certifying body and certificate date here if that changes.

• GDPR (Regulation (EU) 2016/679): Data protection by design and by default, Article 28 processor obligations, and breach notification.
• ISO/IEC 27001: Used as the reference model for our access control, asset management, and incident response practices.
• OWASP Top 10 and OWASP ASVS: Reference for application security review.
• CIS Benchmarks: Reference for cloud and operating system baseline configuration.
• NIS2 (Directive (EU) 2022/2555): Referenced when building for clients in scope, whose supply-chain obligations extend to us.

18. Documentation Available on Request

Procurement and security teams can request the following from office@c9group.dev:

• Our standard Data Processing Agreement
• A mutual non-disclosure agreement
• The subprocessor list and transfer mechanism for a specific engagement
• Completed responses to your security questionnaire or vendor assessment
• A written description of the controls applied to a specific project

19. Contact

See also our Privacy Policy, Terms of Service, and Accessibility Statement.

20. Language