Module 10 — Security and Privacy Architecture

What you'll be able to do

• Explain why health data is special-category or protected data in most regimes, and what that changes in a design
• Draw a data-flow diagram with trust boundaries, run STRIDE over it naming the property each threat violates, and use LINDDUN for privacy threats
• Classify data, and give each class handling rules that a pipeline or policy engine can enforce
• Design identity and access for staff, patients, partner organisations, services and a partner API, including tenant isolation with RBAC and ABAC, and break-glass access
• Design encryption and key management: envelope encryption, a per-region key hierarchy, rotation, key custody, crypto-shredding and pseudonymisation
• Design an audit trail that meets QA13 without leaking patient data into logs, and feed it to detection
• Apply privacy by design, residency rules and zero-trust principles; build security into delivery; and prepare the breach response and assurance evidence a customer will ask for

Coverage note. This module turns Module 3's security and privacy ASRs — QA05 (residency), QA09 (TLS 1.3), QA12 (partner isolation), QA13 (PHI access audit) and QA14 (region-loss recovery) — into a design. Module 3 part 2's Security in depth gives the threat-modelling steps, STRIDE and the SEI tactic groups; this module applies them. Regulations appear as examples — the EU and UK GDPR, the US HIPAA rules — because Lumen's jurisdictions are unnamed. Real obligations depend on the actual jurisdictions and on legal advice. The architect's job is to ask the right questions, design for the answers and produce the evidence, not to interpret the law. Primary sources: Shostack, Threat Modeling: Designing for Security (Wiley, 2014); NIST SP 800-207, Zero Trust Architecture (2020); the OWASP Top 10:2025 and ASVS 5.0; and the LINDDUN privacy threat-modelling framework (KU Leuven).

Why health data raises the bar

What makes it special

Most privacy regimes put health data in a protected class of its own.

• Under the GDPR and UK GDPR, data concerning health is a special category (Art. 9). Processing it is prohibited unless one of a short list of conditions applies, such as the provision of health care (Art. 9(2)(h)). Recital 35 counts information collected while registering for or receiving health services — so a booking for "MRI, Tuesday 09:40, centre 12" is health data even without a diagnosis.
• Under the US HIPAA rules, individually identifiable health information held by a covered entity (a provider such as Lumen) or its business associate (a supplier such as the platform's host) is protected health information (PHI). Appointment dates and the fact that care was given can be part of it.

This module uses PHI as shorthand for health information that identifies a patient, whatever a given regime calls it.

The reasons for the higher bar are practical. A leaked diagnosis cannot be rotated like a password. Imaging can reveal pregnancy, cancer or a psychiatric referral, with real risk of stigma and discrimination. And health records are valuable to criminals because they combine identity, contact and insurance details in one place.

What changes for the architect

Four consequences follow for Lumen. The platform is in scope although it is "only scheduling": a referral, an offer and an appointment are all PHI. Design for the strictest jurisdiction you expect to enter, and make the differences configuration (QA16), not code branches. Accountability shifts the burden of proof: having a control is not enough, you must be able to show it working. And C01, a Supplier-hosted service, puts the Supplier inside the regulated chain together with its own sub-processors, the SMS and email providers among them.

Threat modelling Lumen

Shostack reduces threat modelling to four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job? The first needs a data-flow diagram (DFD): external entities, processes, data stores, the flows between them, and trust boundaries — the lines where data passes between parties or zones that trust each other differently. Every flow that crosses a boundary gives an attacker a foothold, so that is where analysis starts.

The data-flow diagram and its trust boundaries

One region is drawn; the platform zone repeats per region, as in Module 6's physical view. Flows are numbered so that threats and controls can cite them.

Key: rectangles are external entities, rounded boxes are processes, cylinders are data stores, and each labelled box is a trust boundary. Arrows show the direction data flows; the dotted arrow is a key operation.

Two choices in the diagram are deliberate. Partner users get their own identity tenant: F06 left them as an open question, and the identity section explains the answer. And the edge inside TB3 is not a trusted perimeter: flows behind it still use mTLS, as zero trust (below) requires.

STRIDE, mapped to the property each threat violates

STRIDE (Kohnfelder & Garg, Microsoft, 1999) names each threat after the security property it breaks. Reading it as threat → violated property → control family is what turns a list of letters into design work.

Not every threat applies to every element. Microsoft's STRIDE-per-element convention narrows the pass: external entities face spoofing and repudiation; processes face all six; data flows face tampering, disclosure and denial of service; data stores face tampering, disclosure and denial of service, plus repudiation when the store is a log. On Lumen's diagram that turns a blank page into a finite list of element–threat pairs, most of which close quickly.

A STRIDE pass over one flow

DF8, the referral extract, shows why a flow from the customer's own system still crosses a boundary. The platform is a polling consumer of the extract (Module 9, part 2); assume — the case does not say — that it fetches each one from a file endpoint Lumen IT exposes.

The elevation-of-privilege row is the one teams miss. The attacker never touches the platform directly, yet ends up acting with a desk user's rights.

LINDDUN for privacy threats

STRIDE protects the system from attackers. LINDDUN (Deng, Wuyts, Scandariato, Preneel & Joosen, KU Leuven, 2011; maintained at linddun.org) protects people from the system — including from its legitimate operators — and runs over the same DFD. Its seven categories, under their current names, with a Lumen example of each:

Note the inversion: STRIDE treats non-repudiation as a property to protect, and LINDDUN treats it as a threat. Both are right, in different places — staff actions must be undeniable, while patient feedback often should not be attributable. LINDDUN GO, a card-based variant, makes a first pass practical in a workshop of an hour or two.

Data classification

Controls follow classification. A class is useful only when it comes with handling rules specific enough for a pipeline or a policy engine to enforce.

Four rules make the table work:

• Classify at field level in the data model, and let the highest class in a record set the record's class. A slot is class 3 until a patient is booked into it; the booking is class 1.
• Derived data inherits its source's class unless an approved transformation — aggregation with suppression — lowers it. Pseudonymised data stays class 1: under the GDPR, for example, it is still personal data (Recital 26), as Module 6's physical view warned.
• Tags drive automation. Log scrubbers, data-loss checks in the pipeline and infrastructure policies read the class, not a hand-maintained list of fields.
• Secrets and keys sit outside the scheme. They never appear in code, configuration, images, logs or tickets — only in the secrets manager and the KMS.

Identity and access

Four populations, four identity sources

Module 4 introduced federated identity: the platform accepts signed tokens from an identity provider instead of keeping passwords. Lumen needs four providers, because its populations differ in assurance, lifecycle and risk.

SAML 2.0 carries XML assertions through the browser and is common in older enterprise identity providers. OIDC, a JSON and JWT layer on OAuth 2.0, suits single-page and mobile clients as well as APIs. Support whichever Lumen's provider speaks for the workforce, and use OIDC for patients and partners. Do not merge populations to save a provider: a radiographer who is also a patient has two identities, so a staff role can never be reached through a patient sign-in.

Partner organisations as tenants

QA12 makes each of the ~600 partner practices a tenant of one shared portal. Two authorisation models combine:

• RBAC (role-based access control) answers coarse questions: may a partner coordinator upload slots? May centre staff see the day list?
• ABAC (attribute-based access control) answers the question isolation depends on: may this user see this booking? The answer depends on attributes of the user, the resource and the moment.

An illustrative policy, not any product's syntax:

permit  partner_user  read  booking
  when  user.partner_id  == booking.assigned_partner_id
   and  user.region      == booking.region
   and  booking.stage    in [Offered, Accepted, Confirmed, Completed]
   and  now              <= booking.completed_at + 30 days

The last line is purpose limitation in code: a partner needs the patient's details to deliver the study, not for ever. The 30 days are an assumption to agree with the DPO. Policy engines such as Open Policy Agent (Rego) or Cedar keep rules like these out of application code, versioned and testable.

Enforce isolation at every layer, because each catches what the others miss:

1. The token carries partner_id, set by the identity tenant at onboarding. The portal never sends it, and the API never trusts one that arrives in a request.
2. Every endpoint checks object-level authorisation. QA12's URL-editing attack is item API1, Broken Object Level Authorization, in the OWASP API Security Top 10 (2023), and Broken Access Control is still first in the OWASP Top 10:2025.
3. The data layer applies row-level security keyed on the session's partner_id, so a forgotten check returns nothing rather than another partner's rows.
4. Responses say "not found", never "forbidden", so they do not confirm that a record exists — QA12's specified response.
5. Tests and detection close the loop: QA12's automated tests over every partner-facing endpoint at each release, and an alert after 5 refusals in 10 minutes.

Least privilege and break-glass access

Least privilege means each role gets what its work needs and no more. Desk users see referrals in their own region's queue; centre staff see their centre's day list; the Scheduling Manager configures rules without browsing patient records; reporting users see aggregates; Supplier engineers see no PHI by default. Standing administrative rights are replaced by just-in-time elevation — requested, approved, time-limited and recorded. A quarterly access review by each role's owner (assumption) catches the drift that joiners and movers create.

Least privilege will sometimes block urgent, legitimate work: a desk in one region covering another region's queue during a centre closure (QA15), or an engineer repairing a corrupted booking at 02:00. Break-glass access is the designed exception:

• a separate, visible action, never a hidden permission;
• a mandatory reason and ticket reference;
• scope limited to one patient or one queue, and time limited (4 hours, assumption);
• a flagged audit record, and an immediate alert to the security team and Lumen's privacy office;
• review within one working day, checking the stated reason against what was actually opened.

Keep separate emergency accounts, their credentials sealed and stored offline, for the day the identity provider itself is down; any use raises an alert. Break-glass never overrides residency: an engineer in another jurisdiction still goes through the support-access rules below.

Service-to-service identity

Behind the edge, services authenticate each other as strictly as users. Each workload gets an identity issued by the platform — a SPIFFE ID through a service mesh, or the cloud provider's workload identity — carried in a short-lived certificate that rotates automatically every few hours. That gives mTLS on every hop, as Module 6's physical view recommends, and lets authorisation name services: only the notification worker may call the messaging adapters, and only the audit service may write to the audit store.

The same identity removes static credentials. Services gain cloud permissions through workload identity federation and receive database credentials as short-lived secrets from a secrets manager, so there is no password in configuration to leak. A service mesh makes mTLS uniform; the cost is one more platform component to run and upgrade.

The automated partner API

The platform calls the partner group's scheduling API (F02, and Module 5's booking flow), so the partner's authorisation server decides how it authenticates — Module 8 gives the partner group that decision. What to ask for:

• the OAuth 2.0 client credentials grant (RFC 6749 §4.4): machine to machine, with no user in the loop;
• client authentication by a signed JWT (private_key_jwt) or mutual TLS (RFC 8705) rather than a shared client secret, with the private key held in the KMS or the secrets manager;
• sender-constrained tokens — certificate-bound (RFC 8705) or DPoP (RFC 9449) — so a stolen token cannot be replayed from elsewhere;
• narrow scopes (read availability, create booking) and tokens that live for minutes, not days;
• one client registration per region, so a compromise is contained to one region and the partner can see which region is calling.

RFC 9700, Best Current Practice for OAuth 2.0 Security (2025), collects the current guidance. If the partner group later pushes availability changes to the platform, reverse the pattern: the platform's API accepts client-credentials tokens bound to that partner's partner_id, validates every payload and rate-limits the caller. Either way, send the partner only what a booking needs.

Encryption and key management

In transit

QA09 requires TLS 1.3 (RFC 8446) on all authenticated traffic, and Module 6's physical view already terminates TLS at the edge and re-encrypts with mTLS inside the region. Three additions:

• Check every counterparty in discovery. The partner API, the referral endpoint and the messaging providers may not all offer TLS 1.3. One that cannot is a QA09 risk to record and resolve, not a reason to quietly allow TLS 1.2.
• Know where your control ends. Email crosses the internet from the provider to the patient's mail server over whatever that server negotiates, and SMS crosses carrier networks. Transport there is not yours to secure, which is why notification content is minimised.
• Automate certificates — issuance, renewal, short lifetimes — so that an expired certificate never becomes an outage.

At rest: envelope encryption and a regional key hierarchy

Envelope encryption encrypts data with a data encryption key (DEK), generated and used locally, then encrypts — wraps — the DEK with a key encryption key (KEK) that never leaves the key management service (KMS) and its hardware security modules (HSMs). The wrapped DEK is stored beside the data. Bulk data never travels to the KMS; rotating a KEK means re-wrapping DEKs, not re-encrypting data; and every unwrap is a logged, permission-checked call, so revoking one KMS permission makes the data unreadable.

Use two layers:

• Storage-level encryption of every volume, database, bucket and backup, under customer-managed keys. It defeats lost media and provider-side access to storage, but not an attacker who holds application or database credentials.
• Field-level encryption of the most sensitive fields — referral reason, clinical free text, patient contact details — so that a database dump or a curious administrator sees ciphertext. It costs queryability: ciphertext cannot be range-searched or sorted, and exact-match lookups need a blind index (a keyed hash stored beside the field).

QA05 makes the hierarchy regional. Each region's KMS holds its own keys, which cannot be exported, and a key policy refuses requests from other regions' workloads — so a copy that leaks across a border is unreadable (Module 3's encrypt with in-jurisdiction keys tactic). QA14 adds a constraint: the recovery region needs the keys too, so it must sit inside the same jurisdiction. Where a provider has only one region in a jurisdiction — the trade-off point Module 3 flagged — the key design and the DR design fail together.

The numbers shape the hierarchy. Assume, illustratively, $1 per key a month and $0.03 per 10,000 requests; check current prices. One KMS key per patient, at about 2 million patient accounts a year, would cost about $2 million a month after one year, and rising. Five KEKs per region across four regions cost about $20 a month. Requests barely register: even one unwrap per patient session — 25,200 a day, about 630,000 a month over 25 operating days — costs about $2. Per-key fees, not request fees, are what rule out a KMS key per patient. So per-patient DEKs live in a key table inside the jurisdiction, wrapped by a KEK, and unwrapped DEKs are cached in memory for minutes.

Rotation, and who holds the keys

Rotation limits how much data one key protects and how long a stolen key stays useful. Rotate KEKs yearly (assumption): the KMS keeps old versions for decryption, and DEKs are re-wrapped as they are used. Generate new DEKs per period for new data. A suspected compromise is different: it means re-encrypting data under new keys, which takes hours to days at 6.5 million live records. Plan and rehearse it, rather than discover its cost during an incident.

Custody — who controls the key material — is a decision Lumen will have views on, because keys are what would let it cut the Supplier off.

The worked answer records Lumen's choice as an ADR.

Crypto-shredding for erasure

Some stores cannot delete a row. Backups are immutable for their retention period; WORM archives refuse deletion by design; event logs and event-sourced stores are append-only (Module 4); and Lumen archives every record after 18 months online. Crypto-shredding solves erasure for all of them at once: encrypt each patient's data in those stores under that patient's own DEK and, to erase, destroy the key. Every copy of the ciphertext, wherever it is, becomes unreadable.

Five caveats decide whether it works:

• The key table has backups too. If they outlive the erasure deadline, they resurrect the key. Keep the key table's backup retention shorter than the deadline.
• Plaintext copies are not shredded — an export, a log line, an email already sent. Shredding only works alongside minimisation and log hygiene.
• Audit records under legal retention need their own key scope, or erasing a patient also destroys the evidence of who accessed their record.
• Whether ciphertext without its key still counts as personal data varies by regulator. Ask the DPO.
• Erasure of health data is often limited. The GDPR, for example, exempts processing needed for health care or for a legal retention duty (Art. 17(3)). In practice the end of a retention period is the commoner trigger, and the same mechanism serves both. Lumen, as controller, decides which applies.

Pseudonymisation and tokenisation for analytics

Pseudonymisation replaces identifiers so that data cannot be attributed to a person without additional information kept separately (GDPR Art. 4(5)). It reduces risk; it does not make data anonymous.

• A keyed hash (an HMAC with a regional secret) is deterministic, so analysts can join one patient's records within a dataset, yet nobody can reverse it by hashing a list of known patient IDs without the key.
• Tokenisation substitutes a random token and keeps the mapping in a vault, which only the vault service can reverse. Use it where an authorised process must get back to the patient — a clinical-safety follow-up prompted by an analytics finding, say.

Lumen's partner-performance and time-to-offer analytics run inside the jurisdiction on pseudonymised records, with a different key per purpose (LINDDUN's linking). Quasi-identifiers are coarsened: age bands instead of dates of birth, postcode districts instead of full postcodes. Only aggregates leave the jurisdiction.

Audit logging

QA13 says that every read or change of PHI writes an audit record, and that one patient's access history can be produced within an hour. That is three designs: what a record holds, how it is protected, and how it is found.

What an audit record holds

What a record must not hold: the clinical content that was read, request or response bodies, free-text notes, tokens or secrets. The audit trail proves that a record was accessed, not what it said.

Audit every path to patient data: the portals and APIs, the referral sync and the partner adapter, exports and prints, configuration changes that alter patient outcomes (QA10's rules), and direct database access by administrators. Emit records from one shared component at the service boundary — an interceptor every PHI endpoint passes through — so that a new feature cannot forget. A build check that fails when a PHI endpoint lacks the audit annotation turns QA13 into a fitness function.

Volume, as a sizing check. Assume about 20 audited accesses per referral across all actors: patient portal views, desk triage and booking, the centre's day list, the partner, and the system's stage changes. 14,000 × 20 = 280,000 records an operating day; over 300 operating days, about 84 million a year. At an assumed 1 KB each that is about 84 GB a year, or ≈ 118 GB at year-3 volumes (× 1.405) — trivial to store. The effort goes into QA13's one-hour query across more than a hundred million records (≈ 126 million online, over the 18-month searchable period), which needs an index by patient key. So keep two copies inside the jurisdiction: a searchable audit index for the online period, and the WORM archive as the evidential copy.

Fail closed or fail open? If the audit write fails, should the read proceed? QA13 says no record, no access. To stop that costing QA01, each service writes its records synchronously to a highly available, in-region durable buffer and ships them to WORM asynchronously. The buffer then takes a share of the booking path's availability budget — a trade-off point between QA13 and QA01, in Module 8's vocabulary.

Immutability and retention

• WORM storage: object storage with a compliance-mode retention lock, which even the account's own administrators cannot shorten.
• Separation of duties: the audit store lives in a separate account or subscription, administered by people who do not run the platform.
• Tamper evidence: records chained by hash, or periodic signed digests, so that a missing or altered range is detectable.
• Retention from Lumen's schedule (illustratively 6 years), with legal hold for investigations. Audit records are class 1 data themselves: they stay inside the jurisdiction, and only the privacy office and investigators read them.

Keeping patient data out of operational logs

The audit trail is a regulated record that identifies patients by key, on its own pipeline. Operational telemetry — application logs, traces, metrics, error reports — must hold no PHI at all, so that on-call engineers can use it freely. Module 3 part 2's PHI-safe telemetry sets the rules: opaque correlation tokens instead of identifiers, an attribute allow-list and redaction at the collector, no person-level metric labels, and QA05 applied to telemetry too — a scrubber that misses one field should be a defect, not a cross-border transfer. Three additions:

• Keep PHI out of URLs. Paths carry opaque IDs and query strings carry nothing personal, because URLs end up in proxy, CDN and browser-history logs.
• Turn off payload capture in error-tracking and APM tools. Each one is a sub-processor, and most capture request data by default.
• Prove it with a log canary: synthetic patients in pre-production carry distinctive fake values, and a scheduled job searches every log store for them. A hit fails the release.

SIEM and detection

A SIEM (security information and event management system) collects security events and runs detection rules over them. Feed it authentication events, QA12 refusals, role and privilege changes, break-glass use, KMS anomalies, web application firewall events, administrative sessions and configuration changes. These events carry no patient identifiers by construction, so one central SIEM, and a follow-the-sun security team, can serve every region — provided Lumen's DPO accepts staff and partner user IDs crossing borders. Investigators pivot from an alert into the in-region audit index.

Privacy by design

Cavoukian's Privacy by Design: The 7 Foundational Principles (Information and Privacy Commissioner of Ontario, 2009) made privacy a design property, proactive and on by default. The GDPR wrote the idea into law as data protection by design and by default (Art. 25). For an architect it comes down to four practices.

Minimisation, purpose limitation and retention

For every data element, record its purpose, who needs it and for how long — the data inventory under the classification table. Then remove whatever fails the test:

• Partners need the patient's name, contact details, modality, body part and preparation — not the referral reason or clinical history, unless Lumen's clinical lead decides a study type requires them.
• Notifications need nothing clinical.
• Analytics needs no names.
• The referral extract should carry only the fields the platform uses: a request to Lumen IT, made in discovery.

Purpose limitation stops data collected for scheduling being reused — for marketing, say, or to train a model — without a new lawful basis. Module 11 asks the same question of training data.

A retention schedule turns storage limitation into something enforceable. The periods are Lumen's to set as controller; the architect makes each one automatic and evidenced.

Data-subject rights

Most regimes give patients rights over their data. Taking the GDPR's as the example — access, rectification, erasure, restriction and objection, answered within a month, extendable in some cases (Art. 12(3)) — the architecture needs:

• a data map of every store that holds a patient key, so that one request reaches all of them, archive and analytics included;
• a rights-request workflow in the Administration Portal for Lumen's privacy office, with the requester's identity verified through the patient identity service;
• rectification at the source: referral data is mastered in Lumen's referral system, so corrections go there and arrive through the extract, and the platform does not fork the record;
• erasure where it applies, through crypto-shredding;
• an access-history report, which QA13 already produces within an hour; some regimes let patients ask who has seen their record.

The DPIA

The controller owns the DPIA. At Lumen the Sponsor is accountable for each region's assessment and the DPO advises (Module 2's RACI). Under the GDPR the controller must seek the DPO's advice (Art. 35(2)), and the processor must help (Art. 28(3)(f)) — which is why the Solution Architect is Responsible for drafting it. The assessment describes the processing and its purposes, tests necessity and proportionality, assesses the risks to patients, and sets out the measures that address them.

This module's outputs — the DFD, the classification, the controls matrix, the residency design and the retention schedule — form its technical annex. Plan one per region before go-live (O4.1), and revisit it on every material change: a new region, a new sub-processor, a new use of the data. If high risk remains after the measures, the GDPR requires prior consultation with the supervisory authority (Art. 36), which can take weeks. That belongs in the delivery plan's risk log, not in a surprise before launch.

Aggregate-only cross-region reporting

Module 6's physical view sends only aggregates without patient identifiers to the central store. Aggregates can still identify people, so two safeguards go with them:

• Small-cell suppression. Any cell below a threshold — 10, illustratively; the DPO sets it — is suppressed or merged, and rare combinations are coarsened.
• Fixed report definitions rather than ad-hoc queries over the central store, because two overlapping aggregates can be subtracted to isolate one person (a differencing attack). Each new definition gets a privacy review.

Residency and cross-border flows

What may cross a border

QA05 keeps patient data in the jurisdiction where it was collected. The design has to say exactly what may leave.

Three mechanisms enforce the table. Module 8's residency fitness function and region-restricting guardrail stop stores being declared in the wrong place. Egress control makes each region's network refuse outbound traffic except to allow-listed destinations: the messaging providers, the partner API and the central reporting endpoint. And Module 3's tactic binds each request to its region at the identity boundary. Until the new jurisdiction's regulatory position arrives (Module 2's dependency D1), keep everything in region.

Support access from another region

A Supplier that supports the service around the clock will have engineers in other countries. In the EDPB's reading of the GDPR, remote access from another country by a separate entity — a group affiliate or sub-processor — is a transfer even if nothing is stored there; access by the Supplier's own staff abroad may not be, but carries its own risks. Ask the DPO which applies. Either way, a jump host in the region keeps the data's storage local, not the access. The design:

• Day-to-day support works from telemetry, which holds no PHI.
• Access to patient data goes through the break-glass path — just in time, approved, scoped and recorded, through an in-region bastion.
• Only named engineers in locations the DPO has approved may use it, with a transfer mechanism in place wherever the access counts as a transfer — standard contractual clauses or an adequacy decision, in GDPR terms.
• Support tools mask PHI by default, and ticket attachments are scanned, because a patient's screenshot pasted into a SaaS ticketing tool is a transfer to yet another sub-processor.

Sub-processors and notification content

The email and SMS providers are sub-processors: they process patient data on the Supplier's behalf. Under the GDPR the controller must authorise sub-processors, individually or by general written authorisation with a right to object (Art. 28(2)), and the Supplier must pass its own obligations down to them (Art. 28(4)); HIPAA's chain of business associate agreements works the same way. For each provider, establish where it processes and stores content and logs, how long it keeps message bodies, whether it uses the data for its own purposes, and how quickly it reports a breach. Patients' phone numbers and email addresses are class 1, because being on Lumen's list reveals a diagnostic-imaging relationship.

Volume makes the content rule urgent: about 2.1 million SMS and 2.1 million emails a month, each a disclosure to a third party and to whoever sees the patient's lock screen. SMS is not end-to-end encrypted: carriers and aggregators handle it in clear. It previews on locked phones, lands on shared family phones, and reaches whoever inherits a recycled number. So:

• No clinical detail in any SMS: no modality, body part, referral reason or urgency, and no preparation instruction that implies the study ("no food for six hours before your scan with contrast"). No full name and no date of birth.
• A neutral message and a link: "Lumen: there is an update to your appointment. Sign in to view it." Patients who opt in may also receive the date, time and town — never what the study is.
• Links carry no PHI. They lead to sign-in, or to a short-lived, single-use token that shows one confirmation and nothing else.
• Email subjects stay neutral; the detail sits behind sign-in in the portal.
• The sender name reveals the relationship. Recognisability pulls against privacy here; put the trade-off to the DPO rather than settle it in a template.

The rule has a cost side too. SMS is priced per segment of 160 GSM-7 characters, so a message with a study description and a long link spills into a second segment — and SMS is already the largest line in the run-cost model, at ≈ $12,600 a month at the course's illustrative prices (Module 9's worked cloud cost model). Because templates are configuration (QA10), the rule has to be checked whenever a template changes, not once at go-live — the new ASR QA19 in the worked answer.

Zero trust

NIST SP 800-207, Zero Trust Architecture (Rose, Borchert, Mitchell & Connelly, 2020), moves defences from the network perimeter to users, assets and resources: no trust is granted because of where a request comes from or who owns the network. A policy decision point — NIST's policy engine and policy administrator — decides each request, and a policy enforcement point in front of the resource applies the decision. NIST states the model as seven tenets. In paraphrase, applied to Lumen:

Zero trust has a limit at Lumen: patients' and partners' devices are unmanaged, so posture checks cannot apply to them. Where the device cannot be trusted, compensate with MFA, short sessions, rate limits and no bulk export from the partner portal.

Secure delivery

Many breaches enter through software the team ships or depends on, so the delivery pipeline is part of the security architecture. The OWASP Top 10:2025 added A03, Software Supply Chain Failures, widening 2021's vulnerable and outdated components to compromises anywhere in building, distributing or updating software: dependencies, build systems and the pipeline itself.

The SBOM pays for itself the first time a library vulnerability makes the news: "which services, in which regions, run the affected version?" becomes a query rather than a week of searching.

Secrets management. One secrets manager per region, or a vault product such as HashiCorp Vault or OpenBao; dynamic, short-lived database credentials; workload identity instead of stored cloud keys; automated rotation; and the scanning above to catch the leaks that happen anyway.

Policy as code serves twice. Preventive policies stop a non-compliant resource being created — Module 8's guardrails — and detective ones flag drift in what already runs. The same policy files, with their results, are assurance evidence. Verification standards give testers a yardstick: OWASP ASVS 5.0 (2025) for the portals, at a level you choose and record, and the OWASP API Security Top 10 (2023) for the APIs.

Non-production data. No production PHI in development or test. Generate synthetic patients — at year-3 volumes for performance tests — so that test environments hold nothing above class 3.

Incident response and breach notification

NIST SP 800-61 Rev. 3 (2025) recasts incident response as part of risk management, organised around the six functions of the NIST Cybersecurity Framework 2.0 — Govern, Identify, Protect, Detect, Respond and Recover — rather than as a separate lifecycle. The architect's part is to make sure detection, containment and scoping are designed in, not improvised on the day.

Notification law sets the clock. Two regimes as examples — Lumen's obligations depend on its actual jurisdictions:

What the architecture must provide:

• A contracted processor window. Under the GDPR, Lumen's 72 hours start when Lumen becomes aware — in the EDPB's reading, when the Supplier informs it — and the Supplier must notify without undue delay (Art. 33(2)). Delay still leaves patients exposed, so contract a window — within 24 hours of a suspected breach being confirmed (assumption) — and size detection to meet it.
• Scoping within an hour. "Which patients did the compromised partner account read?" is QA13's one-hour query. Without it, the notification goes to everyone, or goes too late.
• Encryption that changes the outcome. In both examples, data encrypted under keys the attacker did not obtain can change whether patients must be told — one more reason to keep keys in separately administered KMS accounts.
• Containment levers: revoke every session of a user, a partner or a tenant within minutes; rotate the partner-API credentials and other secrets without a redeploy; pause one messaging channel by configuration; isolate a region.
• Preserved evidence: the WORM audit trail, forensic snapshots, synchronised clocks.
• Joint playbooks, rehearsed in a tabletop exercise every year (assumption): Lumen notifies; the Supplier investigates; the partner group and each messaging provider have a named contact. These are Module 8's decision rights, applied to the worst day.

Assurance and evidence

Customers rarely audit a supplier themselves; they ask for independent evidence.

Which one Lumen wants depends on its market and its contract: ask in discovery, and inherit the cloud provider's own certifications for the layers it runs (shared responsibility, Module 9). The controls matrix is the spine of the evidence. Each control points to its proof — pipeline results, fitness-function history, penetration-test reports, access reviews, key-rotation logs, DR test reports, tabletop records, the DPIA — and evidence collected automatically survives the second audit as well as the first.

Where security lives in the SAD and in governance

Security is not a separate document. In Rozanski and Woods's terms the security perspective is applied to existing views (Module 6). It adds authorisation and audit components to the Functional view; classification, ownership and retention to the Information view; regions, KMS and trust boundaries to the Deployment view; key rotation, access reviews and incident runbooks to the Operational view; and pipeline controls to the Development view. It also produces the threat model as a secondary model. In Module 6's arc42 outline, the regulation constraint goes in section 2; identity, audit, encryption and residency are cross-cutting concepts in section 8; the security ADRs go in section 9; QA05, QA09, QA12–QA14 and the new ASRs in section 10; and residual risks in section 11.

Governance keeps it true after the document is signed (Module 8): the principle patient data stays where it was collected; fitness functions for residency, isolation, log canaries and notification templates; guardrails that refuse out-of-region, public or unsigned resources; a security architect on the design authority; and the joint architecture board approving decisions that cross into Lumen's decision rights, key custody first among them. Lumen's CISO can block go-live (Module 2's power/interest grid), so make security sign-off an explicit go-live criterion, backed by this evidence.

Check yourself

1. A colleague says the platform holds no health data, because diagnoses and images live in Lumen's clinical systems. How do you answer?
2. Which property does each STRIDE threat violate, and which DFD element types face repudiation?
3. Why does partner_id come from the token and get enforced in the data layer, rather than being sent by the partner portal and checked in the API?
4. Why not one KMS key per patient, and what do you do instead?
5. You crypto-shred a patient's key. Name two places their data can survive unless you designed for them.
6. The audit trail and the application logs both record a partner user opening a booking. Which may contain the patient key, and where may each be sent?
7. Give one privacy reason and one cost reason for an SMS that says "an update to your appointment" rather than "your MRI on Tuesday".
8. A Supplier engineer in another country must repair one patient's corrupted booking tonight. What must be true before they can see it?

Suggested answers

1. A booking is health data. The GDPR, for example, counts information collected while registering for health care (Recital 35), and under HIPAA appointment information can be PHI. Referrals, offers, appointments, preparation instructions and patients' contact details all identify a person's use of diagnostic imaging.
2. Spoofing violates authentication; tampering, integrity; repudiation, non-repudiation; information disclosure, confidentiality; denial of service, availability; elevation of privilege, authorisation. External entities and processes face repudiation, and so do data stores that are logs.
3. Anything the client sends can be edited, which is exactly QA12's attack. The identity tenant sets partner_id at onboarding, so it cannot be changed without forging the token; and row-level security in the data layer means a check missed in one endpoint returns nothing rather than another partner's data.
4. At illustrative KMS prices of $1 per key a month, about 2 million patients a year would cost about $2 million a month. Keep a few KEKs per region in the KMS, and per-patient DEKs wrapped by them in a key table inside the jurisdiction.
5. Any two of: backups of the key table, if they outlive the erasure deadline; plaintext copies such as exports, log lines or emails already sent; data copied in clear out of the encrypted stores, such as an analytics extract; and audit records, which are deliberately kept under a separate key scope.
6. The audit trail holds the patient key; it stays inside the jurisdiction on WORM storage, and only the privacy office and investigators read it. Application logs must hold no patient identifier at all, which is what lets on-call engineers use them freely; they still stay inside the jurisdiction, and only security events derived from them go to the central SIEM, if the DPO agrees.
7. Privacy: SMS crosses carriers in clear, previews on locked screens and reaches shared or recycled phones, so naming the study discloses health information (LINDDUN's detecting). Cost: a longer message spills into a second 160-character segment on what is already the largest line in the run-cost model.
8. A recorded reason and approval through the break-glass path; access scoped to that patient and limited in time; a session through the in-region bastion that is audited and raises an alert; and the DPO's confirmation that access from that country is permitted, with a transfer mechanism in place if the access counts as a transfer. Often telemetry alone will diagnose the fault, without anyone seeing the patient's data.

Exercises — Module 10

Task. Produce the security and privacy architecture for Lumen Diagnostics.

Output: 4–6 pages containing a data-flow diagram with trust boundaries and a STRIDE pass over it; a data classification table with handling rules; a controls matrix — threat → control → ASR — covering QA05, QA09, QA12, QA13 and QA14, plus at least two new ASRs you write; the key-management and residency design; the audit design; three privacy-by-design decisions; and at least two ADRs.

Time: about 5 hours.

Inputs: the case and its Volumes and usage table; your Module 2 stakeholder register and objective O4.1; your Module 3 ASRs, keeping their IDs; your Module 5 context and container diagrams; your Module 6 SAD and physical view; your Module 8 principles and governance model; and the residency handling from your Module 9, part 2 Task.

Threat model

• Draw the DFD from your Module 5 container diagram: the patient portal, the desk and administration portals, the partner portal, the automated partner API, the referral extract, the patient identity service, workforce SSO, the email and SMS providers, and the reporting stores
• Mark every trust boundary, and number the flows that cross one
• Run STRIDE per element; for each threat, name the property it violates
• Run LINDDUN over the same diagram — at least the notification and reporting flows

Classification and controls

• Classes with handling rules a pipeline could enforce: where each may be stored, how it is protected, where it must never appear
• Controls matrix: threat → control → ASR → how the control is verified
• Write at least two new ASRs as testable statements, numbered on from the last ID in your Module 3 list

Keys, residency and audit

• The key hierarchy per region, rotation, custody (with the options you rejected), and how DR keys stay in the jurisdiction (QA14)
• What may cross a border, what may not, and how support from another region works
• Price the key design with labelled, illustrative prices
• Audit: fields, what is excluded, immutability, retention, how QA13's one-hour query is met, and whether the audit write fails closed or open

Privacy and decisions

• Three privacy-by-design decisions, each with the alternative you rejected and who must agree — often the DPO
• At least two ADRs; mark any that cross into Lumen's decision rights for the joint architecture board
• Name every regulation as an example, and every figure the case does not give as an assumption

Self-assessment

Worked answer — Lumen security and privacy excerpts

Attempt the Task before reading this. It is deliberately partial — one trust boundary, three new ASRs, five rows of the controls matrix and one ADR — to show the reasoning, not a complete answer to copy. Every figure the case does not give is an assumption.

Trust-boundary excerpt — partner users crossing into the platform

TB1 to TB3, flows DF3 and DF6: about 1,500 partner users, doubling, on devices nobody at Lumen or the Supplier manages.

New ASRs

Controls-matrix rows

ADR-SEC-01 — Key custody: customer-managed, HSM-backed keys in each region

Status: proposed. It needs the joint architecture board's approval, because patient-data residency and access are Lumen's decisions (Module 8).

Context. QA05 requires keys inside each jurisdiction; QA14 requires them in the recovery region too; QA21 requires per-patient deletion; C01 makes the Supplier the operator. Lumen's CISO wants assurance that the Supplier cannot read data without trace, and asks whether Lumen could cut off access unilaterally at exit.

Options considered.

1. Provider-managed keys. Rejected: no control over deletion, so QA21 fails, and no evidence of each use.
2. Customer-managed keys in each region's HSM-backed KMS, administered by a Supplier key-custodian role kept separate from the platform administrators, with every key use logged to the audit account.
3. BYOK: key material generated in Lumen's HSM and imported into each regional KMS.
4. HYOK: Lumen's HSM outside the cloud, called on every unwrap. Rejected for now: Lumen's HSM would join the booking path, and its availability would have to be priced against QA01's ≈ 8.5-hour outage budget (≈ $11,760 per peak hour) and QA14's 4-hour RTO before anyone could accept it.

Decision. Option 2, with option 3 available for any region at Lumen's request, without changing the design. Per-patient DEKs are wrapped by a regional KEK and kept in a key table inside the jurisdiction, whose backups are retained for 7 days (assumption) so that QA21's 30 days hold.

Consequences.

• Five KEKs per region cost about $20 a month across four regions at the illustrative prices; per-patient KMS keys, at about $2 million a month, are avoided.
• Exit and suspension work through the KMS: disabling a region's KEKs, at Lumen's instruction, makes that region's data unreadable. A disabled key is also an outage, so disabling one needs two-person approval.
• Option 2 does not give Lumen unilateral cut-off: the Supplier administers the keys. If the CISO requires it, BYOK with expiring imported key material that only Lumen re-imports, or HYOK, is the route — the joint board's decision.
• In a jurisdiction where the provider has only one region, QA14's recovery region cannot hold keys in the jurisdiction. That is a risk to raise before the region's design is fixed (Module 2's dependency D1), not a default to accept.
• Key administration becomes a separate role, with its own access reviews and audit.

A complete answer adds the full DFD and STRIDE pass, rows for QA09 and the remaining threats, the retention schedule, the support-access design and a second ADR — the audit write's fail-closed choice, for example.