For the record.

The problem

Every system has security questions that need answering. The people who have the answers are spread across teams — infrastructure, identity, operations, legal, vendors. The questions themselves are well understood. What are we working on. What can go wrong. What are we going to do about it. Did we do a good enough job.

The problem has never been that nobody knows the answers. The problem is that the answers live in one person's head, or in a document nobody reads, or in a conversation nobody recorded. The answer was given in a Teams call and never written down. The decision was made in an email thread nobody can find. Someone was supposed to find something out and forgot, and nobody chased them.

S. is a security delivery orchestration tool. It routes the right questions to the right people, collects their answers with attribution and timestamps, chases them when they do not respond, and presents the status to the people who govern the portfolio. The methodology defines what to ask. The practitioners provide the substance. The app provides the receipts.

If you run a PMO, this is what you have been trying to build from spreadsheets, email threads, and SharePoint sites: a single source of truth for where every project actually is, not where someone says it is, backed by the receipts of who said what, when, and whether it was enough.

The Decision Tree

The assessment follows a deliberate order. Each phase builds on the one before it. You cannot protect what you have not declared. You cannot wrap what you have not mapped. You cannot operate what you have not built controls around.

At every phase, the practitioner faces the same decision: do I answer this, or does someone else? Every "someone else" becomes a delegation with a deadline, a chaser, and a receipt. Every "mine" is an answer attributed to a named person with a timestamp. This is the decision tree.

Every Option Is There for a Reason

The methodology presents structured options at every phase. These are not arbitrary checklists. Each option exists because its presence or absence changes what needs to happen next, what risks apply, and who needs to be involved. They are the signal the system collects. The practitioner who fills them in already knows which ones apply. The app collects that knowledge and makes it countable across projects.

Phase 0 — Data Declaration Options

Data types in play (16 options)

Each one changes the legal obligations, breach notification requirements, retention rules, and security controls. "Special category (Art 9)" triggers explicit consent requirements and higher security standards. "Children's data" triggers age verification and parental consent. "Credentials / secrets" means compromise gives direct access to other systems. The combination defines the blast radius of a breach.

Obligations that apply (15 options)

Each creates specific, enforceable requirements. "NIS Regulations 2018" applies to operators of essential services. "NHS DSPT" has a submission deadline of 30 June 2026. "PCI DSS" applies to any system handling cardholder data. The obligations selected determine which CAF outcomes are mandatory vs advisory and which evidence will be required at audit.

Known risk exceptions (8 options)

Each names a specific pattern of knowingly carrying risk. "Legacy system — no remediation path" is fundamentally different from "Deferred remediation (with timeline)" — one has a plan, the other does not. "Risk appetite exceeded (escalated)" means someone senior needs to know. Each pattern requires a different management response.

Phase 1 — Data Journey Options

Seven stages, four questions each, between 3 and 7 sub-prompts per question. Roughly 160 individual control points across the full journey. Each sub-prompt represents a control that can be present or absent.

Take the Collect stage as the worked example:

Q1 — "What are we collecting?" (7 sub-prompts)

Q2 — "What can go wrong?" names specific threats: injection, spoofing, over-collection, availability dependencies, integrity loss, unnamed assumptions.

Q3 — "What are we going to do about it?" names specific controls: input validation, rate limiting, logging, fallback behaviour, rejection criteria.

Q4 — "Did we do a good enough job?" is the self-assessment: adversarial testing, independent review, residual risk documentation, proportionality.

The same structure repeats at Transmit, Process, Store, Share, Retain, and Dispose. Each stage has different sub-prompts because data faces different risks at different points in its lifecycle.

Phase 2 — Cyber Wrapper Options

Nine discovery areas, each with between 8 and 15 options:

Phase 3 — Operational Upkeep Options

Eight areas, each with 7-9 options:

Controls — What Admin and Management Can Do

The app has three control surfaces: practitioner, management, and admin. Each has different capabilities and different visibility.

Practitioner controls

• Create systems and name them
• Work through all four phases: declare data, map the journey, describe the wrapper, confirm operations
• Answer questions or delegate them (mine / someone else)
• Nominate stakeholders and assign them areas
• Record assumptions and track their test status
• Add evidence and link it to outcomes
• Assess CAF/DSPT outcomes with IGP checklists and rationale
• Create ownership links to find owners of things referenced in the assessment
• Nominate candidates for ownership confirmation
• View the event stream for their systems
• Export the assessment

Management controls

• View the portfolio dashboard: headline numbers across all systems
• View the per-system breakdown table: every system ranked by answers, stages, outcomes, assumptions, evidence, delegations, decisions, comments, lens findings, last active
• View the 30-day activity sparkline across the portfolio
• View the accountability map: all stakeholders, delegations, and accountability requests across all systems
• View the ownership gaps page: unresolved ownership links across the portfolio
• Revoke any pending delegation, accountability request, stakeholder invite, or ownership candidate
• View risk decisions, delegations, comments, topology, debt, budgets, time allocation, and snapshots per system
• Receive the weekly digest with machine-generated status

Admin controls

• System health monitoring (database, storage, sessions)
• User management (roles, notification channels)
• Framework configuration (custom frameworks, risk edge management)
• Notification configuration (email/SMTP, Slack, Teams)
• Authentication configuration (WebAuthn, OIDC, SAML, header-based)
• Storage configuration (local filesystem, S3, Azure Blob)
• Rate limit, chaser, deadline, snapshot, and backup configuration
• Audit log viewer and initial setup wizard

The revocation capability

Management and admin can revoke any pending request across all accountability mechanisms:

Every revocation requires a reason. Every revocation notifies the affected person. Every revocation is audited with attribution and timestamp. No request disappears silently.

One Place, With Receipts

What the application collects is a single, unified event stream where every action is attributed to a person, timestamped, and connected to the thing it is about:

• Audit events — who changed what, when, in which section
• Decisions — who decided what, through what channel, with what rationale, and whether a later decision superseded it
• Delegations — who asked whom to do what, when, with what deadline, whether they responded
• Deadline events — what was due when, whether it was met, missed, or extended
• Comments — who said what about which part of the model, and when
• Ownership events — who was nominated, who confirmed, who referred, who was revoked

"TLS is in place" is a statement. "TLS is in place, confirmed by Sarah Chen on 14 March via the web interface" is evidence. The difference is the difference between a policy document and a control.

What this means for a PMO

Status is not collected. Status is observed. The PMO does not ask project leads "are you on track?" and receive an optimistic narrative. The PMO looks at the dashboard and sees: 14 delegations overdue, Dispose stage untouched, three assumptions untested past their deadline, last activity 11 days ago. That is status. It is not someone's interpretation of status. It is the measured state of the work.

Scale that across a portfolio. Twenty projects. The PMO can see, without a single status meeting: which projects have complete assessments and which have gaps, which stages are being neglected, which stakeholders are bottlenecks, which projects are active and which have gone quiet. That is the difference between a PMO that chases status and a PMO that reads it.

For the record.

The people who know the system have already done the thinking. What has always been missing is a structured way to collect the evidence of that thinking from the people who hold it, attribute it, track it, and present the status to the people who need to govern it.

S. defines the phases: declare the data, map the journey, describe the wrapper, confirm the operations, assess the outcomes. At every step, the decision tree applies: mine, or someone else's. The app routes the questions, collects the answers, attributes them, timestamps them, chases non-responses, and presents the statistics and status.

• Here is where we are, with evidence.
• Here is who is responsible, with receipts.
• Here is what we do not know, with deadlines.
• Here is what is overdue, with names.
• Here is how we got here, with a timeline.
• Here is how this compares to our other systems, with numbers.
• Here is whether we are improving, with trends.

All in one place. All from the same source. All generated as a consequence of collecting the answers, not as an additional reporting burden.

For a PMO, this is the operating system. Not another tool to check. The tool that replaces the checking. Status is not collected, it is observed. Reporting is not written, it is generated. Bottlenecks are not reported, they are measured. The PMO stops chasing and starts governing.

For the record.