Cybersecurity and compliance: GDPR, hardening, backup, and recovery

Framing

Why cybersecurity is a different problem now

Cybersecurity used to be a perimeter problem. A firewall at the edge, antivirus on the endpoint, and a backup tape in the closet. The perimeter kept the bad actors out, the antivirus kept the malware off the workstations, and the backup recovered the data when something went wrong. The model was simple, the model was effective, and the model is no longer enough.

The threat model has changed. The perimeter is the internet. The endpoint is a mobile device on a coffee-shop WiFi. The data is in the cloud, in the SaaS application, in the API, in the document store. The attacker is automated, distributed, and persistent. The defender has to cover every surface; the attacker only has to find one. The asymmetry is the problem.

The technology that addresses the new threat model is a connected cybersecurity practice: endpoint protection, email security, network security, access control, vulnerability assessment, hardening, backup, recovery, and continuous monitoring — operated as a single practice, on shared standards, by the same team that operates the rest of the connected ecosystem. The result is a system the buyer can audit, replicate, and ultimately own.

This article sets out the architecture, the operating model, and the economics of connected cybersecurity. It is written for organisations that have lived through the perimeter problem and are ready for the connected practice.

The shift from perimeter security to connected practice is the same shift that the rest of IT has made: the move from a portfolio of disconnected tools to a single, integrated, operationally mature platform. The portfolio worked when the perimeter was the only attack surface. The portfolio does not work when the attack surface is the entire distributed system. The connected practice is the answer, and the answer is the same for security as it is for hosting, voice, and AI: one architecture, one team, one accountability.

The cybersecurity practice is also the test of whether the connected ecosystem is actually connected. A security practice that does not integrate with the rest of the platform is a separate product. A security practice that integrates with the device management, the email, the network, the access, the backup, the hosting, the voice, the eSIM, and the AI is a layer in an architecture. The connected ecosystem delivers security as a layer, and the layer is the difference between a feature and a capability.

The transition is also an opportunity to reconsider the relationship between the security practice and the rest of the IT. In the perimeter era, security was an add-on, bolted to the edge of the network, with a different team, a different budget, a different reporting line, and a different relationship to the rest of the organisation. In the connected-ecosystem model, security is a layer in the architecture, with the same team, the same budget model, the same reporting line, and the same architectural commitment to inspectability, replicability, and the option to leave. The relationship is structural, and the structural relationship is what makes the practice scale.

Architecture

What a connected cybersecurity practice actually is

The practice covers six surfaces: endpoint, email, network, access, backup, and recovery. Each is operated to the same standard. Each connects to the rest through documented interfaces. Each is auditable. The six surfaces together form a system, not a portfolio of products.

Endpoint protection covers the device layer: laptops, desktops, mobile devices, and servers. The protection is continuous, with behavioural detection, signature updates, and centralised management. The endpoint is hardened to a published standard, with the configuration documented and the deviations alerted.

Email security covers the email layer: phishing, malware, business email compromise, and data loss prevention. The protection is at the gateway, with sandboxing, link rewriting, attachment analysis, and policy enforcement. The email is auditable, with the message trace queryable.

Network security covers the network layer: segmentation, firewall, intrusion detection, and intrusion prevention. The network is monitored continuously, with the traffic patterns baseline-established and the deviations alerted. The network is documented, with the topology and the rules inspectable.

Access control covers the identity layer: single sign-on, multi-factor authentication, privileged access management, and conditional access. The access is policy-based, with the policy documented and the deviations alerted. The access is auditable, with the login events queryable.

Vulnerability assessment covers the discovery layer: continuous scanning, penetration testing, and configuration review. The findings are prioritised, with the remediation tracked. Backup covers the recovery layer: automated, offsite, encrypted, and tested. Recovery covers the response layer: documented, rehearsed, and time-bound.

The six surfaces are not a product catalogue. They are a coverage map of the cybersecurity capability space. The buyer does not buy endpoint protection; the buyer buys the endpoint capability, the email capability, the network capability, the access capability, the backup capability, and the recovery capability, each as a layer in the same architecture. The buyer can start with one capability, expand to others, and replace any capability without losing the rest. The coverage map is the architectural commitment, and the architectural commitment is the buyer's right to evolve.

The continuous protective monitoring is the property that makes the practice operationally mature. The practice is not a set of tools that the buyer runs occasionally. The practice is a set of tools that the buyer runs continuously, with the telemetry aggregated, the baselines established, the anomalies detected, the responses automated, and the reporting delivered. The continuous monitoring is the difference between a cybersecurity practice and a cybersecurity product, and the difference is the buyer's right to know what is happening at any time.

The continuous protective monitoring also produces the data that the rest of the practice needs. The telemetry from the endpoint, the email, the network, the access, the backup, and the recovery feeds the alerting, the baselining, the incident response, and the post-incident review. The data is the practice. Without the data, the practice is a collection of tools; with the data, the practice is an operational system. The continuous monitoring is the difference, and the difference is operational, not just technical.

Operating model

Self-serve, consultation, or managed

The cybersecurity practice supports three engagement models. The first is self-serve: the buyer purchases the tools, deploys them, and operates them. The documentation is public. The community is active. The buyer can run the practice themselves. This is the right model for organisations with strong internal security capability.

The second is consultation: the buyer engages us for an assessment, an architecture, an implementation, or a specific remediation project. We scope the work, deliver it, and hand over. The buyer owns the result. This is the right model for organisations that need specialist depth for a specific challenge.

The third is managed: we operate the practice end to end. Monitoring, ticketing, changes, incident response, threat hunting, and continuous improvement. The buyer gets a single point of contact. This is the right model for organisations that want the capability without the overhead of operating it themselves.

Across all three models, the engineering standards are the same. The hardening baseline is the same. The monitoring thresholds are the same. The incident response process is the same. The architecture is consistent; the engagement depth varies.

The compliance framework follows the practice. The relevant standards are GDPR, BFSG and the European Accessibility Act, EN 301 549, the EU–US Data Privacy Framework, ISO 27001, and BSI IT-Grundschutz where applicable. The privacy policy names the lawful basis for each processing activity. The data transfer impact assessment is documented. The data is exportable; the architecture is portable.

The three engagement models are not tiers. They are entry points. An organisation with strong internal security capability can start with self-serve, with the practice as a set of tools the team operates. An organisation with internal capability but a specific gap can engage us for consultation on the gap. An organisation that wants the capability without the operational overhead can engage us for managed operation, with the practice as a service. The models are not exclusive; the buyer can move between them as the needs evolve.

The compliance framework is not a separate product. It is the documentation of the practice. The relevant standards (GDPR, BFSG, EN 301 549, EU–US Data Privacy Framework, ISO 27001, BSI IT-Grundschutz) are documented in the practice, the data flows are documented, the sub-processors are documented, the lawful bases are documented, the data transfer impact assessments are documented, the security measures are documented, the incident response process is documented, the recovery procedures are documented. The compliance framework is the architectural record, and the record is auditable end to end.

The practice supports the buyer's right to evolve. The buyer can add a surface (start with endpoint, add email, add network, add access, add backup, add recovery), replace a surface (change a tool, change a vendor, change an approach), and retire a surface (consolidate, optimise, simplify). The evolution is supported by the practice, not constrained by it. The buyer is in control of the surface set, the engagement depth, and the architectural properties. The practice serves the buyer's evolution, not the other way around.

Economics

The case for a connected practice over a portfolio of tools

The economic case for a connected cybersecurity practice is the elimination of the integration tax. A portfolio of security tools — one for endpoint, one for email, one for network, one for access, one for backup — has a cost that is the sum of the licences plus the integration work plus the security review per tool plus the procurement cycle per tool plus the audit per tool. The total cost is typically 30% to 50% higher than the licences alone.

A connected practice collapses the visible costs into one commercial relationship and eliminates most of the hidden ones. One support model, one escalation path, one set of standards, one procurement process. When something breaks, one team is accountable. When something needs to change, one team scopes it. When the organisation grows, the practice grows with it on the same architecture.

The economic case compounds over time. A portfolio of tools drifts as each vendor updates on its own schedule, deprecates on its own schedule, and changes pricing on its own schedule. The integration work is ongoing. The security review is ongoing. The procurement is ongoing. The connected practice is operated as a system, with a single roadmap, a single architecture, and a single set of updates.

The total cost of ownership over a three-year window is typically 25% to 40% lower for the connected practice, including the avoided integration work, the avoided security review, the simplified procurement, and the unified audit. The architecture is the difference. The architecture is the savings.

The economic case for a connected practice is the elimination of the integration tax, and the integration tax is the cost of having multiple security tools that do not work together. The integration tax is invisible on any single invoice, but it is real: the analyst's time to correlate events across tools, the engineer's time to maintain the integrations, the manager's time to reconcile the reporting. The connected practice eliminates the integration tax by replacing the multiple tools with a single system, and the elimination is the largest single line item in the three-year economic case.

The avoided vendor risk is the second-largest line item. A portfolio of tools has multiple vendors, multiple contracts, multiple renewal cycles, and multiple deprecation timelines. The buyer is exposed to each vendor's pricing, each vendor's roadmap, each vendor's lifecycle, and each vendor's support model. The connected practice has one vendor, one contract, one renewal cycle, and one deprecation timeline. The exposure is consolidated, and the consolidation reduces the total risk exposure in a way that compounds over the three-year window.

The economic case is also strengthened by the buyer's ability to switch costs between capital and operating expense, between one-time and recurring, between fixed and variable. The connected practice supports all of these, because the practice is a system with documented costs, not a portfolio of tools with opaque costs. The finance team can model the practice, the finance team can optimise the practice, and the finance team can report on the practice. The transparency is the property that makes the practice financeable, and the financeability is what makes the practice investable.

Risk

Architectural questions, not sales claims

The risk of a connected cybersecurity practice is concentration: one provider for all six surfaces. The mitigation is architectural transparency. Every tool is inspectable. Every configuration is documented. Every change is auditable. The architecture is not a black box.

The risk of lock-in is the buyer becoming dependent on a specific tool, a specific vendor, a specific platform. The mitigation is open standards and the explicit option to leave. The tools support standard data formats. The configuration is exportable. The buyer can take the architecture and operate it independently, with a different tool, a different vendor, or a different platform.

The risk of a breach is real for any security practice. The mitigation is data minimisation, explicit access, human checkpoints, traceable work, cost boundaries, and continuous protective monitoring. The practice is engineered to reduce the probability and the impact, not to promise that neither will occur.

The risk of regulatory non-compliance is real for organisations in regulated industries. The mitigation is documented compliance: GDPR, ISO 27001, BSI IT-Grundschutz, the published sub-processor list, the published data transfer impact assessment, the published professional indemnity cover under Markel Insurance SE policy ON.MPI.64092, and the published legal identity. The buyer can audit every part of the compliance picture.

The architectural questions a buyer should ask are these. Can I see the configuration? Can I see the monitoring? Can I export the data? Can I leave without losing the work? The answer to all four is yes.

There is a fifth risk worth naming: the risk of security tool sprawl. An organisation that adds security tools over time, each to address a specific gap, ends up with a portfolio of tools that does not work together, does not report together, and does not respond together. The connected practice is the mitigation: a single architecture with a single set of tools, each chosen for the role it plays in the system, each integrated by design, each replaceable without losing the rest. The architecture prevents the sprawl by enforcing the integration at the platform level.

There is a sixth risk worth naming: the risk of a security incident that exceeds the practice's response capability. The mitigation is the documented incident response process, the rehearsed runbooks, the external escalation paths (law enforcement, regulatory authorities, insurance carrier), and the post-incident review. The platform supports each of these with tooling: the runbooks are accessible from the practice console, the external escalations are pre-staged, and the post-incident review template is built in. The response capability is not a hope; it is a rehearsed process.

The risk model is also supported by the documentation. The risk register, the risk treatment plan, the risk acceptance decisions, and the risk review cadence are all part of the practice. The buyer can see the risks, the treatments, the acceptances, and the reviews. The risk model is not a sales artefact; it is an operational artefact, and the operational artefact is the buyer's right to know what is being protected, how, and at what cost. The risk model is the buyer's right, and the right is documented.

Implementation

A week-by-week sequence

Week 1: Assessment. We map the current cybersecurity posture — endpoint, email, network, access, backup, recovery — and identify the gaps. The output is a document the buyer can audit.

Week 2: Architecture. We design the target state — which tools move to the practice, which stay with existing vendors, what the integration points are, what the monitoring thresholds are. The architecture is documented and inspectable.

Week 3: Build. We provision the tools, configure the policies, deploy the monitoring, and set up the alerting. The build is on a test environment first, then promoted.

Week 4: Migration. The endpoints, the email, the network, the access, and the backup are migrated in sequence. The migration is reversible at every stage. The buyer retains the option to operate the new system, the old system, or both in parallel.

Week 5 and beyond: Operation. The practice is live. The monitoring is active. The incident response is rehearsed. The compliance is documented. The buyer has a single point of contact.

The sequence is not rigid. A buyer can start with one surface — endpoint, email, or backup — and expand. The practice is designed for incremental adoption, not for a forced all-at-once migration.

The implementation sequence is designed to validate the architecture early. The first week establishes the baseline: which surfaces are protected, which are not, which are at risk, which are at the right level. The second week designs the target state: which tools move to the practice, which stay with existing vendors, what the integration points are, what the monitoring thresholds are. The third week builds the practice on a test environment, with the security hardening applied. The fourth week migrates the surfaces in sequence, with the legacy arrangements maintained during the transition.

The implementation sequence is also designed to validate the practice against real threats. The first month establishes the baselines. The second month tunes the monitoring thresholds based on the real telemetry. The third month runs the first tabletop exercise, with the incident response process tested against a simulated scenario. The fourth month runs the first penetration test, with the practice evaluated against real attack patterns. The validation is continuous, not a one-time check, and the validation is part of the practice, not a separate service.

The implementation sequence is also designed to validate the buyer's investment. The first month establishes the baseline cost, the second month establishes the operational cost, the third month establishes the response cost, and the fourth month establishes the improvement cost. The total cost of ownership is established within the first quarter, and the establishment is the buyer's basis for the investment decision. The investment is not a hope; it is a measured outcome, and the measured outcome is the buyer's right to know the economics.

FAQ

Five plain-language questions

What is the difference between a connected practice and a portfolio of security tools? A connected practice operates all six surfaces as one system, with shared standards, shared monitoring, and shared accountability. A portfolio of tools operates each surface independently, with separate licences, separate support, and separate integration work.

Will you guarantee no breach? No mature security provider can guarantee that. What we can guarantee is data minimisation, explicit access, human checkpoints, traceable work, cost boundaries, and continuous protective monitoring. These are the engineering principles that reduce the probability and the impact.

What about GDPR compliance? The privacy policy names the lawful basis for each processing activity. The data transfer impact assessment is documented. The sub-processor list is published. The compliance framework is GDPR, ISO 27001, BSI IT-Grundschutz, and the EU–US Data Privacy Framework. The buyer can audit every part.

Can I keep some of my existing tools? Yes. The practice supports incremental adoption. You can move one surface at a time, or keep a specific tool where it makes sense and integrate it.

How does pricing work? Per surface, scoped to the deployment. There is no bundled opaque pricing. The buyer knows what is being protected, what the protection costs, what the support costs, and what the option to leave costs.

For organisations that have not yet adopted a connected cybersecurity practice, the most common question is about the first surface to migrate. The first surface is usually the one with the highest risk and the lowest coverage: endpoint, email, or backup. The first surface establishes the architectural pattern, the operational model, and the integration approach. The other surfaces follow the same pattern, with the same model, with the same approach. The first surface is not a pilot; it is the foundation.

For organisations that have already adopted a connected practice, the most common question is about the next surface. The next surface is informed by the first: what worked, what did not, what the team learned, what the monitoring showed. The practice is the same; the surface is different. The buyer can move from endpoint to email to network to access to backup to recovery, with the same architecture, the same team, the same support model, and the same option to leave. The practice is the constant; the surface is the variable.

For organisations that operate in regulated industries, the practice supports the regulatory audit. The audit is not a separate engagement; the audit is part of the practice. The evidence (logs, configurations, baselines, alerts, responses, post-incident reviews) is collected continuously, stored centrally, and made available to the auditor on demand. The audit cost is reduced, the audit duration is reduced, and the audit outcome is improved. The practice is auditable, and the auditability is the property that makes the practice regulator-acceptable.

Worked example

A concrete case with numbers

Consider a 50-person professional services firm with a portfolio of security tools acquired over five years from different vendors. The endpoint protection is from one vendor, the email security from another, the network firewall from a third, the access control from a fourth, the backup from a fifth, and the vulnerability scanning from a sixth. The annual cost of the licences is approximately EUR 28,000. The hidden cost — integration work, security review per vendor, procurement per vendor, audit per vendor, offboarding risk per vendor — is estimated at another EUR 18,000 per year in staff time and contractor fees.

Under a connected cybersecurity engagement, the six surfaces consolidate into one practice, operated by one team, on shared standards. The annual run-rate drops to approximately EUR 22,000, with the integration work, the security review, the procurement, and the audit consolidated. The hidden cost is largely eliminated because one team operates the whole practice.

The trust argument is not the cost reduction alone. It is the architecture: the firm can audit the configuration, replicate the deployment, change the tools, change the operator, and leave the practice at any time. The compliance is documented. The data is exportable. The architecture is the firm's, not the vendor's. The vendor-portfolio problem is gone for security too.

The numbers are illustrative, not a quote. Every deployment is different. The principle holds: a connected cybersecurity practice, operated by one team, on shared standards, with the option to leave, costs less in total than a portfolio of tools from different vendors — and it works better, because the practice is a system, not a collection.

Consider a second worked example: a 200-person financial services firm with a portfolio of security tools acquired over eight years, with eleven different vendors, with eleven different contracts, with eleven different renewal cycles, and with an annual security review that takes six weeks and costs EUR 80,000 in staff time and external auditor fees. The annual licences cost EUR 95,000. The hidden cost of the portfolio (integration, security review, procurement, audit, offboarding risk) is estimated at EUR 60,000 per year.

Under a connected cybersecurity engagement, the eleven surfaces consolidate into a single practice, operated by a single team, on shared standards, with shared monitoring, with shared reporting, and with shared accountability. The annual run-rate drops to approximately EUR 72,000, with the integration cost, the security review, the procurement, and the audit consolidated. The hidden cost is largely eliminated, with the annual security review dropping from six weeks to two weeks. The total saving is approximately EUR 163,000 per year, recurring, and the architectural property is the same as in the smaller worked example: one team, one practice, one accountability, and the option to leave at any time.

The third worked example: a 500-person healthcare provider with a portfolio of security tools acquired over a decade, with fourteen different vendors, with the annual security audit taking twelve weeks and costing EUR 120,000 in staff time and external auditor fees. The annual licences cost EUR 140,000. The hidden cost of the portfolio is estimated at EUR 90,000 per year. The total cost is approximately EUR 350,000 per year, with the audit consuming significant operational attention. Under a connected cybersecurity engagement, the fourteen surfaces consolidate into a single practice, with the annual run-rate dropping to approximately EUR 105,000, the audit duration dropping to three weeks, and the hidden cost largely eliminated. The total saving is approximately EUR 245,000 per year, recurring, with the additional benefit of reduced operational attention to audit and increased attention to security. The architectural property is the same: one team, one practice, one accountability, and the option to leave at any time.