Security and Compliance Needs

Back to Server Setup · Growth Projections · Patch Management · Service Offerings

This stage establishes the industry-specific requirements — data residency, encryption, access logging and the rest — that shape architecture decisions from day one. It is the fourth stage of a server setup, and the phrase “from day one” is doing real work in it. Most of these requirements are cheap to satisfy while a system is being designed and expensive or impossible to satisfy afterwards.

Three examples of why the timing matters. A region is chosen once; moving a live dataset to a different one later is a migration project, not a configuration change. Encryption at rest applied to an existing volume usually means creating a new encrypted volume and copying everything to it, with downtime. And an audit trail that starts in March cannot tell you what happened in February — that gap is permanent, and it is exactly the period an investigator will ask about.

1. Where the Requirements Come From

We start from your actual obligations rather than a generic checklist, because the list differs enormously and the cost of over-applying it is real. In practice the sources are:

• Law and regulation — general data protection rules, sector-specific regimes for finance, healthcare, telecoms and critical infrastructure, and national rules that may be stricter than the regional baseline.
• Standards you are certified against or are pursuing, which impose controls directly and, just as importantly, impose evidence requirements: you must be able to show the control worked, not only that it exists.
• Your customers' contracts. Frequently the strictest source of all. Enterprise customers impose residency, encryption, audit and right-to-audit terms that go beyond anything a regulator asks for, and those terms are already signed.
• Your insurer. Cyber policies increasingly specify controls as conditions of cover, which makes them requirements whether or not anyone thinks of them that way.

2. Data Residency Covers More Than the Database

This is the requirement most often believed to be satisfied when it is not, because “the data” turns out to mean seven things.

The first three are usually handled. The last four are where the problems are. A disaster recovery site is deliberately somewhere else, and “somewhere else” may be somewhere not allowed. Application logs are full of personal data that nobody classified as personal data. Monitoring and analytics are often third-party services in another jurisdiction. And access is itself a transfer: a support engineer in another country viewing a screen has accessed the data, whatever the disk is doing.

The architecture consequences are concrete: which region, whether managed services in that region offer what you need, where backups land, where the DR site sits, where telemetry is shipped, and how support is staffed. Each is fixed early and awkward to reverse.

3. Encryption Is a Question About Keys

“Is it encrypted?” is nearly always answered yes and nearly always under-specifies the requirement. The useful questions are:

• At rest — disks, databases, object storage, and backups and snapshots, which are frequently missed. An encrypted database whose backups sit unencrypted in a bucket is not an encrypted system.
• In transit — not only to the browser. Between application and database, between services, and to third parties. Internal traffic is regularly left in the clear on the assumption that the network is trusted.
• Who holds the key. This is the requirement behind the requirement. Provider- managed keys mean the provider can technically decrypt your data; customer-managed keys mean you can revoke access and you can also lose it permanently. Where the demand is that the provider cannot read the data, that is a different architecture, not a checkbox.
• Rotation and recovery — how often keys change, who can authorise it, and what happens if a key is lost. Key custody is the part with genuine operational risk: badly handled, encryption is an excellent way to lose your own data irreversibly.

4. Access Logging Has to Be Usable as Evidence

• Log the administrators, not just the users. Application audit trails are common; records of who logged into the server, who read the database directly, and who changed a firewall rule are much rarer — and those are the accesses that matter most.
• Write it somewhere the subject cannot edit it. A log an administrator can alter proves nothing about an administrator. Ship it off the host, append-only, immediately.
• Retain it long enough. Retention is usually set by your obligations, and breaches are often discovered months after the fact — a 30-day retention answers nothing about a six-month-old intrusion.
• Make sure it can be read. Logs that are never reviewed and cannot be searched satisfy the letter of a control and none of its purpose. This is where the requirement becomes a logging platform decision rather than a checkbox.
• Keep personal data out of it where you can — because the log inherits every obligation attached to what is written into it, including residency and the right to erasure.

5. The Rest of the List

• Identity and access — central identity, multi-factor authentication, least privilege, and a process for removing access when someone leaves. Joiner-mover-leaver is unglamorous and is where most real exposure accumulates. See user management and permissions.
• Network segmentation — what can reach what. Decided by the network design, therefore decided early, and informed by the dependency map.
• Patching with a deadline. Most regimes expect vulnerabilities to be fixed within a stated time, which makes it a process requirement rather than an intention — see patch management.
• Backup integrity and tested restores. Being able to restore is the control; having backups is not. Covered under backup and recovery.
• Incident response with notification deadlines. Several regimes require notification within a fixed number of hours of becoming aware. Meeting that needs detection, a decision path and contact details prepared in advance — not drafted during the incident.
• Your suppliers' compliance. Where a provider processes your data, their certifications, their locations and their subcontractors become part of your position.

6. What This Changes in the Build

The point of gathering these early is that each maps to a decision someone would otherwise make by default:

• Residency → region, backup destination, DR location, telemetry routing, support model.
• Encryption and key custody → storage choice, key management service, whether managed services are usable at all.
• Access logging → a log pipeline off the host, with retention and immutability, sized and budgeted from the start.
• Segmentation → network layout, which is difficult to re-cut once workloads are placed.
• Evidence requirements → what has to be recorded routinely, because evidence cannot be reconstructed retrospectively.

What You Get

• A requirements register: each obligation, where it comes from, and what it actually demands in technical terms.
• The residency map — all seven locations, with the permitted region for each.
• An encryption and key-custody design, including backups and internal traffic, and a stated answer on who can decrypt.
• A logging design covering administrator access, with retention, immutability and an owner for review.
• The architecture decisions each requirement forces, recorded with their reasons, so a later change to the estate does not quietly break a control.
• The evidence position: what is recorded routinely and where an auditor would find it.