Cybersecurity Architecture

A security architecture is not a diagram of purchased products. It is the set of trust assumptions, boundaries, controls, responsibilities and recovery choices that protect a real operation. We begin with the business services that create obligations: receiving orders, delivering care, operating machinery, paying staff, serving customers, publishing data or administering identities. For each service we identify the information and technology it relies on, the people and organisations it serves, the external dependencies it cannot control and the consequences of loss of confidentiality, integrity, availability or accountable action.

The current-state map follows data and authority rather than the organisational chart. It records users, administrators, workloads, service accounts, devices, applications, APIs, networks, cloud tenants, suppliers, repositories, backups and management planes. Internet exposure matters, but so do internal paths, inherited trust, remote support, shared credentials, unmanaged exports and tokens that cross environments. Unknown assets and undocumented connections are reported as uncertainty; they are not silently coloured green to make the assessment look complete.

Threat modelling keeps the work proportional. We identify plausible threat actors, objectives, entry paths, privilege routes, sensitive actions and abuse cases for the agreed scope. A public marketing site, a financial workflow and an industrial control environment do not receive the same assumptions. We distinguish a vulnerability from an exploitable path and an exploitable path from a material business scenario. Severity combines consequence, exposure, prerequisites, existing safeguards and recovery difficulty rather than copying a scanner score into an executive priority list.

The design basis also records legal, contractual, insurance and customer-assurance requirements supplied by the client. A framework can organise decisions, but mentioning NIST, ISO, CIS, PCI DSS or another standard does not establish compliance. The proposal states whether the commission is an architecture review, a target design, implementation support, a control assessment or preparation for a separately governed audit. Certification, formal attestation, legal interpretation and penetration testing are not implied by the word security.

Pricing follows the evidence boundary. Estate size, number of tenants and locations, cloud and on-premise mix, OT or regulated data, source quality, architecture access, workshops, threat scenarios, required artefacts, implementation involvement and validation depth all affect the work. We do not promise that an architecture will prevent every incident, satisfy every auditor or remove every risk. Acceptance proves that the agreed decisions and artefacts were produced and tested as scoped; risk treatment and operational outcomes remain owned, observed and maintained over time.

Modern services rarely sit behind one meaningful perimeter. Staff work remotely, suppliers administer systems, customers use portals, applications call APIs and automated agents act through service identities. The architecture therefore asks who or what is requesting access, which resource and action are requested, from what device and context, under which policy, for how long and with what evidence. Network location may contribute a signal, but it is not treated as sufficient proof of trust.

The identity model covers workforce, customers, partners, administrators, applications, workloads, machines and recovery accounts. We document authoritative identity sources, federation, enrolment, authentication, authorisation, session lifetime, device posture, credential and secret storage, joiner-mover-leaver events, delegated administration and emergency access. Duplicate directories, local accounts and unmanaged service credentials are visible exceptions with owners and treatment dates—not footnotes left outside the target diagram.

Least privilege is expressed as an operating rule rather than a slogan. Roles and policies grant the minimum useful action over a defined resource and time. Privileged tasks may require stronger authentication, managed devices, approval, just-in-time elevation, recorded sessions or a dedicated administration path. Separation of duties is applied where one compromised or dishonest identity should not be able to initiate and approve the same consequential act. Break-glass access is narrow, monitored, tested and followed by credential rotation and review.

Authentication strength must match the threat and the account. Multi-factor authentication can reduce several credential risks, but it does not repair excessive authorisation, unsafe recovery, stolen sessions, malicious OAuth consent or an over-privileged workload. We examine phishing resistance where the risk warrants it, token audience and lifetime, conditional access logic, device registration, legacy protocols, password reset, help-desk verification and session revocation. Controls are tested against bypass and recovery paths, not only the normal sign-in screen.

Zero Trust is used as a design discipline, not a product label or instant migration promise. Resources, identities, devices, applications and data flows receive explicit policy and telemetry; access is evaluated per session or action where the platform permits it; trust is not inherited merely from being inside a network. The roadmap may reuse existing controls and progress by service. A complete rebuild is not assumed, and no environment is declared Zero Trust merely because a vendor feature has been enabled.

The target architecture shows where trust changes and where a control can prevent, constrain, detect or help recover from misuse. We trace north-south and east-west traffic, administrative access, application calls, data movement, software delivery, supplier connections and backup paths. Segmentation follows the protect surface and plausible attack path rather than creating arbitrary network zones. Each boundary has a purpose, enforcement point, policy owner, failure mode, logging source and method of verification.

Cloud and SaaS services require a shared-responsibility map specific to the provider and service model. Provider security does not configure the client's identities, data permissions, tenant settings, keys, applications or recovery choices. We record organisation and account structure, landing zones, network exposure, identity federation, privileged roles, logging, encryption and key ownership, workload identity, secret handling, posture controls, data residence requirements and provider dependencies. Multi-cloud language is not added unless the actual estate and operating capacity justify it.

Application and API security are connected to architecture and delivery. Trust boundaries, input handling, authentication and authorisation, object access, secrets, dependency provenance, build permissions, artefact integrity, deployment approval, runtime isolation and audit events are considered according to risk. The OWASP ASVS can help specify testable application controls, but using it as a reference does not establish that a product meets a level. Version, selected requirements, evidence and verifier must be explicit when it forms part of acceptance.

Data protection follows lifecycle and use. We classify the information necessary for the scoped service, map collection, transfer, processing, storage, export, retention and deletion, and connect each state to owners and access rules. Encryption choices include endpoint, protocol, key custody, rotation, backup and recovery implications; the word encrypted is not accepted without context. Tokenisation, minimisation, field-level restrictions and controlled export may reduce exposure more effectively than adding another perimeter appliance.

Endpoints, email, networks, applications, identity and data controls are designed as a coherent system. Defence in depth does not mean buying overlapping tools without a decision model. We examine whether controls share reliable identity, whether policies conflict, where telemetry is lost, what happens during provider failure and which manual step still carries critical authority. Duplicate products may be consolidated; a simple compensating control may remain where replacement would create greater risk. Every recommendation states dependency, owner, expected risk treatment and evidence of completion.

A preventive control is incomplete without an understood failure state. We identify the events that would show misuse, policy bypass, privilege change, configuration drift, suspicious data movement, control outage or recovery activity. Logs require a defined source, clock, identity, retention, integrity boundary, access model and owner. Collecting everything forever is neither a strategy nor automatically lawful. Telemetry is selected because it supports a detection, investigation, obligation or control verification that somebody is responsible for operating.

Detection coverage is mapped to material scenarios. Each rule or analytical method names the observable behaviour, required fields, evaluation point, threshold or logic, severity, likely false positives, triage owner, response deadline and evidence preserved. Missing telemetry and disabled agents are monitored as control failures rather than interpreted as quiet systems. A dashboard that shows alerts without case ownership, escalation or closure evidence does not create an operating detection capability.

Containment must preserve business and safety constraints. The architecture defines which account, device, token, network route, workload or integration can be isolated; who may authorise the action; what dependencies may fail; and how access can be restored. Automated containment is limited to scenarios with tested confidence and bounded consequence. Where immediate isolation could endanger people, destroy evidence or stop a critical service, the response path carries the appropriate human authority and alternative safeguards.

Recovery is designed before an incident. We record critical service dependencies, recovery priority, acceptable data loss and interruption targets supplied by the client, backup and replica separation, administrative independence, restoration credentials, clean-room needs and validation steps. A successful backup job does not prove recoverability. Representative restore and failover exercises must verify usable data, applications, identity, configuration and operational handover. The architecture does not promise an RPO, RTO or availability level unless the full dependency chain can support and the contract states it.

Incident readiness joins technical and organisational paths. Contact trees, provider escalation, evidence handling, communications, legal and regulatory decisions, customer obligations and post-incident change ownership must be named for the applicable scope. Architecture work may produce runbook inputs and exercise scenarios, but it is not an undisclosed 24/7 incident-response retainer. If continuing monitoring, response, forensics or crisis support is required, its hours, authority, channels and commercial terms are commissioned separately in writing.

The gap register connects each finding to a business service, threat scenario, affected asset, current safeguard, target state, recommended treatment, dependency, accountable owner and evidence. We avoid false precision: a score can help compare a defined set of observations, but it does not reveal every unknown exposure. Findings are separated into confirmed, inferred and not yet testable. Where the evidence is incomplete, the next action may be discovery or validation rather than immediate purchase.

Roadmap priority reflects material risk and delivery reality. Foundational work such as identity ownership, asset discovery, administrative separation, backup isolation or central logging may enable several later controls. Quick wins are useful only when they reduce a real path. Large changes are divided into decision gates, pilots, migrations and rollback points. Budget, skills, maintenance load, supplier lock-in, user friction and operational capacity are included so the target is implementable rather than an aspirational diagram that the organisation cannot run.

Acceptance is evidence-led and scenario-based. Depending on scope, evidence may include approved diagrams and decision records, policy exports, configuration snapshots, identity and role tests, access denial, secret rotation, log arrival, alert triage, isolation, restore exercises, application-security checks and exception handling. Each case has a precondition, actor, action, expected result and captured evidence. A screenshot of a green console is not enough when the rule, tested identity, time and source cannot be reproduced.

Penetration testing, vulnerability scanning, code review and configuration assessment answer different questions. They may validate parts of the architecture, but none alone proves that the overall service is secure. The proposal states which methods are included, the authorised targets and times, data-handling rules, test safety, severity model, retest and reporting. Intrusive testing is never implied or performed without explicit written authority. Independent assurance may be recommended where separation from the designer is valuable or required.

The architecture remains a living decision record. New suppliers, acquisitions, remote work, applications, AI agents, regulations, incidents and material configuration changes can alter the trust model. Review triggers, exception expiry, access recertification, key control indicators, test cadence and document ownership are therefore part of handover. Continuing governance or managed operation exists only if purchased. Security risk cannot be transferred to a diagram or a consultancy; the organisation retains its decisions, accounts, data and accountable owners.