How Do You Protect Our Data?

Short Answer

In a well-built custom system, data is protected by four practical layers: encryption in transit and at rest, role-based access controls, secure hosting with enforced patching and backups, and an audit trail of who did what. Any agency working with business data in the UK should be working to GDPR standards by default, including data minimisation, purpose limitation, and the ability to export or delete records on request. Beyond that baseline, the specific controls depend on the sensitivity of the data: a system holding payment information has tighter requirements than one holding internal task records.

What Data Protection Actually Looks Like

Data protection is a stack of controls applied at every layer of the system.

Encryption in transit. All traffic between users and the system uses HTTPS with modern TLS configuration. There should be no fallback to HTTP, no mixed content, and no weak cipher suites. This is table stakes, and any agency that does not enforce it should not be trusted with business data.

Encryption at rest. Sensitive fields (passwords, payment tokens, API keys, personal identifiers) are encrypted in the database. Passwords specifically are hashed with a slow algorithm like bcrypt or argon2, not stored in any reversible form. Database backups are encrypted on the storage layer.

Access controls. Users see only the data their role permits. Admin access is separated from operator access, and operator access is separated from end-user access. Administrative actions require elevated authentication. The system tracks who has access to what and makes it easy to revoke when someone leaves.

Secure hosting. The hosting environment is patched regularly, monitored for intrusion, and isolated from other tenants. Servers do not run with default credentials. Production access is restricted to named individuals via SSH keys, not shared passwords. Backups are taken daily, tested periodically, and stored separately from the live system.

Audit trail. Significant actions (record changes, exports, permission changes, logins from new locations) are logged. The log is tamper-resistant and retained long enough to support investigation if needed. Without an audit trail, you cannot answer “who did this?” when something goes wrong. See What Is an Audit Trail and Why It Matters for a fuller explanation.

Why Businesses Need This

Data protection is no longer optional in any business handling personal data of UK or EU residents. GDPR sets the legal floor, but the practical floor is often higher: a client running a B2B service expects their data to be safe; a regulated industry has sector-specific requirements (FCA, ICO, NHS); a SaaS product targeting larger customers will face procurement security questionnaires that the system must be able to answer honestly.

The cost of getting this wrong runs in two directions. A breach has direct costs (notification, regulatory penalties, legal fees) and indirect costs (reputational damage, client churn). Building protection in from the start is several times cheaper than retrofitting it after an incident.

What to Look For

• TLS and HSTS enforced everywhere. Check the live site. It should redirect HTTP to HTTPS and use modern TLS configuration. Free SSL Labs tests will show the grade.
• Password handling that follows current best practice. Hashed, salted, never stored in plain text or recoverable form. Password reset flows should not reveal whether an email is registered.
• Role-based access with the principle of least privilege. Users should only see and do what their role requires. Admin access should be limited to a small named group.
• Backups with restore tests. Backups that have never been restored are not backups. The system should be restored to a test environment periodically to verify the backup works.
• Documented incident response plan. If something goes wrong, who is notified, in what order, with what data preserved for investigation.

Common Mistakes

The most common mistake is treating security as a feature added at the end rather than a default applied throughout. By the time security is “added”, the system has dozens of places where it should have been built in.

Over-relying on the hosting platform is the second. AWS or DigitalOcean handle the physical infrastructure and base operating system; the application layer is still your responsibility.

The third is granting too much access too easily. Many breaches start from a former employee whose access was never revoked, or a third party with broader permissions than they needed.

How We Approach This

We build to GDPR standards by default, with encryption in transit and at rest, role-based access controls, secure hosting, and audit trails. For systems handling more sensitive data (payments, regulated personal data, health information), we apply additional controls appropriate to the sensitivity level. Keeping those controls maintained over time is part of ongoing software support.

Discuss Your Specific Requirements

If your project involves regulated or sensitive data, that is the right conversation to have early. The Security Hardening page covers the technical depth of how we structure protection. Further reading is available in the Knowledge Center.