Security governance, risk and compliance: systems, data and dependencies

Lesson map

Lesson 03 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 From services to components"]
  N2["3.2 Reading the dependency map"]
  N3["Lab — Northstar dependency map and owners"]
  N4["3.3 Data and where it goes"]
  N5["3.4 Dependencies outside the organisation"]
  N6["3.5 From map to scenarios and evidence"]
  N7["Concepts — the listing counts names, it does not gra"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 From services to components"]
  N2["3.2 Reading the dependency map"]
  N3["Lab — Northstar dependency map and owners"]
  N4["3.3 Data and where it goes"]
  N5["3.4 Dependencies outside the organisation"]
  N6["3.5 From map to scenarios and evidence"]
  N7["Concepts — the listing counts names, it does not gra"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[3.1 From services to components]
    |
    v
[3.2 Reading the dependency map]
    |
    v
[Lab — Northstar dependency map and owners]
    |
    v
[3.3 Data and where it goes]
    |
    v
[3.4 Dependencies outside the organisation]
    |
    v
[3.5 From map to scenarios and evidence]
    |
    v
[Concepts — the listing counts names, it does not gra]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) map the systems and data behind each priority service; (2) find shared dependencies and unowned components; (3) turn the map into risk scenarios and evidence requests.

3.1 From services to components

Chapter 1 asked Northstar to name its services before choosing products. The next step is to list what each service depends on. The appointment portal needs a web host, the scheduling database, the identity provider that signs staff in and an email relay that sends confirmations. Case management needs its own database, the identity provider and file storage for documents. The volunteer roster is a shared spreadsheet that also uses the identity provider and the email relay for reminders. Writing these lists with the service owners is quick, and it often surprises them, because few people see the whole chain behind a service they use every day.

3.2 Reading the dependency map

The lab turns the lists into a small map. The identity provider supports all three services, so a failure or compromise there would affect everything at once. The email relay supports two services but has no owner. The roster spreadsheet also has no owner. Every other component has one. These two facts change Chapter 1's priorities. A restore test of the scheduling database is still valuable, but if staff cannot sign in, a perfect restore will not reopen the portal. The map therefore adds the identity provider to the restore exercise scope and adds ownership of the email relay and roster to the operations director's decision list.

Lab — Northstar dependency map and owners

"""Northstar dependency map: which services each component supports, and unowned components."""
deps = {"appointment portal": ["web host", "scheduling database", "identity provider", "email relay"],
        "case management": ["case database", "identity provider", "file storage"],
        "volunteer roster": ["roster spreadsheet", "identity provider", "email relay"]}
owners = {"web host": "IT", "scheduling database": "IT", "identity provider": "IT", "case database": "Casework",
          "file storage": "IT", "email relay": None, "roster spreadsheet": None}
use = {}
for s, cs in deps.items():
    for c in cs: use.setdefault(c, []).append(s)
for c, ss in sorted(use.items(), key=lambda x: -len(x[1])):
    print(f"{c}: supports {len(ss)} service(s); owner {owners[c] or 'NONE'}")
print("shared by all three:", [c for c, ss in use.items() if len(ss) == 3])

Run with python3 lab_deps.py. Verified output:

identity provider: supports 3 service(s); owner IT
email relay: supports 2 service(s); owner NONE
web host: supports 1 service(s); owner IT
scheduling database: supports 1 service(s); owner IT
case database: supports 1 service(s); owner Casework
file storage: supports 1 service(s); owner IT
roster spreadsheet: supports 1 service(s); owner NONE
shared by all three: ['identity provider']

3.3 Data and where it goes

Systems hold data, and data create obligations. Northstar's scheduling database holds client names, contact details and appointment reasons, some of which may reveal health or financial hardship. Case management holds detailed case notes. The roster holds volunteers' contact details. For each, the team records what data exist, why they are kept, who can see them, where copies go and how long they are retained. They find that appointment confirmations sent through the email relay include the appointment reason, which is more than clients need in an email. Reducing that content is a cheap change that lowers privacy risk without affecting the service.

3.4 Dependencies outside the organisation

Several components are run by suppliers: the web host, the identity provider and the email relay. Northstar cannot inspect their internals, but it can ask what assurance they offer, read their terms on outages and data handling and check whether it can export its data if it needs to leave. NIST CSF 2.0 places supply chain risk management within its Govern function, which matches Northstar's situation: the board does not need technical detail, but it does need to know which services depend on suppliers and whether anyone has checked them. The team records each supplier, the service it supports, the evidence available and the date it was last reviewed.

3.5 From map to scenarios and evidence

The map produces sharper scenarios in the Chapter 1 format. If the identity provider is unavailable, staff cannot reach any service, and Northstar has not tested a fallback sign-in. If the unowned email relay is misconfigured, appointment confirmations could reach the wrong people, and nobody reviews its settings. If the roster spreadsheet is shared too widely, volunteer contact details may be exposed, and access has never been reviewed. Each scenario names an evidence request: the identity provider's status history and fallback options, the relay's configuration, and the roster's sharing list. Evidence requests keep the strategy honest, because they show which beliefs have been checked and which are still assumptions.

Worked example

Northstar lists components behind three services, finds the identity provider shared by all three and two unowned components, trims appointment reasons from emails and writes three evidence-backed scenarios.

Synthetic case. All Northstar systems, suppliers and data are fictional; NIST CSF 2.0 and the NIST Privacy Framework are real.

Errors and limits

Maps omit informal tools staff use. Supplier assurance varies in scope. A shared component may have hidden redundancy the map does not show.

Concepts — the listing counts names, it does not grant a key

The laboratory program builds a dictionary of supporters. Each component collects the services that name it. Sorting uses the negative of that collection's length, so the widest support prints first. An empty owner field prints a marker rather than a blank cell. The closing line keeps a component only when its collection holds every service. None of those steps reads the signed scope, so a printed row is not a key.

Lesson table; scroll horizontally to read all columns →

The first signed scope still excludes case management until next quarter. Keeping the row does not move that exclusion.

Decision flow — three questions, three different rows

flowchart TD
  A["A row from the dependency listing"] --> B{"Which question is being asked?"}
  B -->|Who supports every service| C["Collection length equals 3"]
  C --> D["The identity provider joins the restore exercise"]
  B -->|Who has no owner| E["The printed owner is NONE"]
  E --> F["Email relay and roster go to the director's list"]
  F --> G["Do not reconfigure either one yet"]
  B -->|May this row be opened| H{"Is the component inside the first signed scope?"}
  H -->|Case database, no| I["Keep the row. Do not open the database"]
  H -->|Portal chain, yes| J["The row is still not permission"]

Worked example — the case-database row is not a key

The engineer sees the case database in the verified listing and reaches for an export. The row is present so the identity provider's support of every service stays visible, including a service outside the first scope. She leaves that database closed. No suspicious account was found, so there is nothing new to report to its owner; the row alone is not an incident. Separately, the marker NONE on the email relay and on the roster spreadsheet is the missing-owner fact. Both names go to the operations director's decision list. She does not reconfigure the relay and she does not edit the spreadsheet. The identity provider's support of all three services is why that component joins the restore exercise, and she does not trade that reason for the NONE lines.

Synthetic case. No suspicious case-management account appears here. The row is only the printed listing, and the listing's order is the verified sort.

Apply

• EX055 — A row outside the scope. The laboratory listing includes the case database. The first scope excludes case management. Should the row be deleted, and may the engineer open that database?
  Show marking criteria

  Rubric: 3 = keep the row so the shared identity dependency stays visible; do not open or investigate the case database;; 2 = do not open it;; 1 = delete the row or investigate;; 0 = none.
• EX056 — Two facts that must not be swapped. The listing prints NONE for the email relay and shows the identity provider supporting all three services. Which fact is the missing owner, which fact adds a component to the restore exercise, and may the engineer reconfigure the relay?
  Show marking criteria

  Rubric: 3 = NONE is the missing owner and goes to the director's decision list; support of all three is why the identity provider joins the restore; do not reconfigure the relay;; 2 = the two facts are different;; 1 = reconfigure the relay;; 0 = none.

Exercises

• EX021 — Portal chain. List the four components behind the appointment portal.
  Show marking criteria

  Rubric: 3 = web host, scheduling database, identity provider, email relay;; 2 = four;; 1 = vague;; 0 = none.
• EX022 — Universal dependency. Which component supports all three services?
  Show marking criteria

  Rubric: 3 = the identity provider;; 2 = identity;; 1 = email relay;; 0 = none.
• EX023 — Unowned components. Which two components have no owner in the lab?
  Show marking criteria

  Rubric: 3 = the email relay and the roster spreadsheet;; 2 = two;; 1 = vague;; 0 = none.
• EX024 — Restore scope change. Why does the map add the identity provider to the restore exercise?
  Show marking criteria

  Rubric: 3 = without sign-in a restored portal still cannot reopen;; 2 = sign-in;; 1 = vague;; 0 = none.
• EX025 — Decision list. What did the map add to the operations director's decision list?
  Show marking criteria

  Rubric: 3 = owners for the email relay and roster;; 2 = ownership;; 1 = vague;; 0 = none.
• EX026 — Sensitive appointment data. Why is appointment reason sensitive?
  Show marking criteria

  Rubric: 3 = it may reveal health or financial hardship;; 2 = sensitivity;; 1 = vague;; 0 = none.
• EX027 — Email content fix. What cheap change lowers privacy risk in confirmations?
  Show marking criteria

  Rubric: 3 = remove the appointment reason from emails;; 2 = minimise;; 1 = vague;; 0 = none.
• EX028 — Data record fields. Which facts are recorded for each data set?
  Show marking criteria

  Rubric: 3 = what, why, who sees, where copies go, retention;; 2 = five;; 1 = vague;; 0 = none.
• EX029 — Supplier questions. What can Northstar check about suppliers without inspecting internals?
  Show marking criteria

  Rubric: 3 = assurance offered, outage and data terms, export ability;; 2 = three;; 1 = vague;; 0 = none.
• EX030 — CSF placement. Where does NIST CSF 2.0 place supply chain risk management?
  Show marking criteria

  Rubric: 3 = in the Govern function;; 2 = Govern;; 1 = Protect;; 0 = none.
• EX031 — Supplier record. What does the team record for each supplier?
  Show marking criteria

  Rubric: 3 = service supported, evidence available, last review date;; 2 = record;; 1 = vague;; 0 = none.
• EX032 — Identity scenario. Write the identity provider scenario's evidence gap.
  Show marking criteria

  Rubric: 3 = no tested fallback sign-in;; 2 = untested fallback;; 1 = vague;; 0 = none.
• EX033 — Relay scenario. What consequence follows a misconfigured email relay?
  Show marking criteria

  Rubric: 3 = confirmations could reach the wrong people;; 2 = misdirection;; 1 = vague;; 0 = none.
• EX034 — Roster evidence. Which evidence is requested for the roster scenario?
  Show marking criteria

  Rubric: 3 = its sharing list;; 2 = sharing list;; 1 = vague;; 0 = none.
• EX035 — Honest strategy. How do evidence requests keep the strategy honest?
  Show marking criteria

  Rubric: 3 = they show which beliefs are checked and which are assumptions;; 2 = evidence;; 1 = vague;; 0 = none.

Synthesis

A dependency map turns named services into shared components, owners, data obligations, supplier checks and evidence-backed scenarios.

Continue studying — lesson 03 (chapter 03 of 20)

← Chapter 02 · Course chapter index · Chapter 04 →

Continue to the next authored lesson.