Security Statement

1. Isolation between customers

Every site runs in its own container, with its own database and its own credentials. Sites do not share an application runtime, a filesystem or a database user. There is no shared PHP process serving several customers, which is the mechanism behind most cross-customer compromises on traditional shared hosting.

A site that is compromised through its own application code, an out-of-date plugin for example, is contained within its own environment. It cannot read another customer's files or query another customer's database, because the credentials to do so do not exist inside it.

2. Encryption

In transit. TLS on every public connection. Certificates, including wildcards, are issued and renewed automatically for every site and mailbox, so a site cannot end up serving plaintext because someone forgot to renew. Administrative access to infrastructure is over SSH with key-based authentication and password authentication disabled.

At rest. Backup snapshots are encrypted on the machine that creates them, before they leave it, so the storage service holds no decryptable copy. Account passwords are stored as salted hashes and cannot be read or recovered by anyone, including us. Credentials the platform stores in order to operate are encrypted.

3. Backups an attacker cannot destroy

The common failure in a serious intrusion is that the attacker reaches the backups too, and a customer discovers that their recovery plan was inside the blast radius. The backup design starts from that assumption.

Backups are append-only over the network. A machine can create and read its own snapshots. It cannot delete them. An attacker who has fully compromised a server, including its credentials and its repository password, still cannot destroy one byte of its backup history. This has been verified by exercise rather than assumed from configuration: a deletion attempted with full credentials was refused, with every snapshot surviving.

Backups are taken nightly to a service we operate in the United Kingdom, with a monthly copy held offsite. Snapshots are deduplicated and encrypted before leaving the source machine.

Backups are restore-tested automatically every day. A sample is restored into a disposable environment and compared against the source. A backup that has never been restored proves nothing, and we have found real cases where a backup reported itself complete and could not in fact be restored. Testing the restore rather than the backup is the only way that gets caught.

4. Access control and accountability

• Two-factor authentication is available on every account, at every plan level.
• Role-based access within an account, so a team member gets what their role needs.
• Scoped API keys that carry only the permissions selected when the key is created, rather than full account access.
• Internal access is limited to the people who operate the platform, granted on a need-to-know basis and removed when a role ends.
• Administrative actions are audit logged with the actor, the action and the time.
• Destructive operations against production hosts are blocked at the tooling layer, not left to convention, so an operator cannot stop or destroy a customer's running service by mistake.

5. Protection in front of your site

Every hosted site sits behind our own security and caching layer, described on the ScaleShield page. It provides a managed web application firewall against known attack patterns, bot filtering, rate limiting, per-country rules, and automatic escalation to a higher security tier when a site comes under attack.

Hostile traffic is rejected before it reaches the customer container, so an attack costs the site no CPU, no memory and no database connections. Rules are maintained by us across the whole platform, and a change reaches every site in about five seconds.

Verified search engine crawlers are checked against the ranges published by each search engine and allowed through, so hardening a site never costs it search visibility.

6. Monitoring and integrity

Uptime is checked every minute from outside our own network, because a check that runs inside the network cannot tell you what the internet sees.

Automated health checking runs continuously across the platform's subsystems and alerts the operations team. Hosted WordPress installations are scanned against published checksums so that modified core files are detected rather than discovered later.

7. Incident response

Where a security incident affects personal data we process on your behalf, we will notify you without undue delay and in any event within 48 hours of becoming aware, with what we know at the time and further detail as the picture develops. The full commitment is in the DPA.

Service-affecting incidents are published on the status page.

8. Certifications

We do not currently hold ISO 27001 or SOC 2 certification, and we will not imply otherwise. A certification we do not hold is not something to hint at in a security questionnaire, and a supplier that overstates one is telling you something about the rest of its answers.

What we can give you instead is the mechanism: this statement, the technical and organisational measures in Annex II of the DPA, and direct answers to your questionnaire from the people who build and run the platform. If certification is a hard requirement for your procurement process, tell us early at security@g7cloud.com and we will tell you plainly whether we can meet it and on what timescale.

9. Reporting a vulnerability

Email security@g7cloud.com. We will acknowledge within two working days and keep you updated until it is resolved.

We will not take action against anyone who reports a genuine vulnerability in good faith, gives us a reasonable opportunity to fix it before disclosing, and does not access, modify or delete another customer's data while investigating.