WINGMAN by Peak Defence
WINGMAN keeps requirements, assets, risks, controls, incidents and audits as linked records. Every use case below runs on the same records, and AI proposes while people decide.
A risk register, a control matrix, an asset list, an audit tracker. Each copies a little of the others and drifts apart.
Every record exists once. A control links to the risks it reduces, the clauses it meets and the evidence that proves it.
The data model
Pick an entity type to see what it records and what it links to. Risks link to risks and assets to assets, which gives risk hierarchies and dependency maps.
Use cases
Each use case runs on the same records. Open one to step through it on the graph.
Assess each vulnerability by the risk it raises, and fix first what matters most.
Review risks with all the context gathered since last time, plan their treatment, and keep several levels of risk consistent.
Find new risks without duplicates, link them to everything relevant, and let signals start identification or a re-review.
Assess how long each service can be down and what recovery it needs, from the services, risks and controls already recorded.
Support every stage of an incident, from the first signal to the risk review it should trigger.
Evaluate a supplier for feasibility before onboarding, and keep watching it afterwards.
Assess a planned change for impact, decide the controls needed before and after it, and keep one set of records as the result.
Run the reviews good practice expects (assets, documents, risks, incidents, access) on a calendar instead of from memory.
Run security work through plans and tasks, with briefs, reminders and escalations, and ask "what needs to be done" against everything the model knows.
Implement a new regulation or standard by reusing and linking what already exists, then drive the rest with tasks and plans.
Prepare the ISO 27001 management review and NIS2 management body oversight with complete inputs, logged decisions and planned follow-up.
Keep processing chains and their risks current, and support data protection impact assessments.
Keep an AI use case registry and link each use case to its obligations, risks and controls.
Sectors and regulations
Each page takes one regulatory regime and shows which registers WINGMAN keeps for it, how the governance cycle runs on the graph, and what the use cases look like from that angle.
Run the information security office of an essential or important entity from one registry of suppliers, assets, risks, incidents, vulnerabilities, threats and tasks.
Run operational, financial, reputational and other non-financial risk management on one model, and catch the events that should move it.
Keep the whole ISMS in one model, with control ownership, recurring reviews, management review and evidence that holds up over an audit period.
Treat each AI use case as an asset with its own risks, controls and work plan, and show conformity with the EU AI Act from the same records.
Design CRA compliance into how products are built and supported, from risk assessment and SBOM to vulnerability handling and reporting.
Keep the record of processing, DPIAs, processors, data subject requests and breaches as linked records, so accountability can be shown at any time.
Videos
Short explainers of the model and of individual use cases.
Plays from youtube-nocookie.com. YouTube sets no cookies until you press play.
Case studies
Case studies are being prepared. In the meantime, the videos show the use cases on anonymised data.
The data model
Each line reads left to right as a sentence. A link is stored once and shown from both ends.
| From | Relationship | To | Why the link helps |
|---|---|---|---|
| Requirements | met by | Controls | One control can cover clauses from several standards. |
| Requirements | maps to | Requirements | A NIS2 article maps to ISO 27001 and DORA clauses already covered. |
| Requirements | interpreted in | Documents | The policy states how the clause applies here. |
| Controls | described in | Documents | The written rule and the practice sit side by side. |
| Controls | reduces | Risks | Residual risk follows the status of its controls. |
| Controls | protects | Assets | Coverage of each asset, or each product, is visible. |
| Controls | proven by | Evidence | Expiry shows when proof goes stale. |
| Controls | improved by | Tasks | Planned controls carry work |
| Tasks | part of | Plans | Progress rolls up into programmes and calendars. |
| Risks | rolls up to | Risks | Process risks roll up into enterprise risks. |
| Risks | affects | Assets | Impact rests on what the organisation actually runs. |
| Risks | involves | Suppliers | Third-party risks name the supplier. |
| Assets | depends on | Assets | Dependency maps: where each service and dataset resides. |
| Suppliers | provides | Assets | Third-party dependencies are part of impact analysis. |
| Suppliers | bound by | Documents | Contracts, DPAs and exit plans sit with the supplier. |
| Threats | exploits | Vulnerabilities | Scenarios are specific, not generic. |
| Threats | drives | Risks | Likelihood follows the threat picture. |
| Vulnerabilities | found on | Assets | Exposure is located on a real system. |
| Vulnerabilities | raises | Risks | Open weaknesses push the score up; fixes bring it down. |
| Vulnerabilities | fixed by | Tasks | Remediation has an owner and a deadline. |
| Signals | indicates | Risks | Early warning between scheduled reviews. |
| Signals | points to | Threats | Threat news reaches the register. |
| Signals | reports | Vulnerabilities | Scanner results and advisories open vulnerabilities. |
| Signals | concerns | Suppliers | Supplier monitoring feeds early warning. |
| Signals | escalates to | Incidents | Triage decisions are recorded. |
| Incidents | realises | Risks | Post-mortems update ratings and treatments. |
| Incidents | affects | Assets | Impact and reporting scope are clear at once. |
| Incidents | involves | Suppliers | Supplier-caused incidents are traced to the supplier. |
| Incidents | reported in | Documents | Notices to authorities, customers and suppliers are kept. |
| Incidents | followed up by | Tasks | Lessons learned turn into work. |
| Audits | reads | Documents | Documents show the controls the organisation claims to have. |
| Audits | scoped to | Assets | One audit can cover several products, each with its own controls. |
| Audits | assesses | Suppliers | Supplier evaluations use the audit method. |
| Audits | tests | Requirements | Audit scope is traceable to clauses. |
| Audits | tests | Controls | Claimed and operated are checked together. |
| Audits | examines | Evidence | Auditors see the proof that already exists. |
| Audits | raises | Findings | Each observation is recorded once. |
| Findings | becomes | Conclusions | A confirmed finding is the result for its clause. |
| Conclusions | judges | Requirements | Compliance status per clause and scope, year on year. |
| Findings | resolved by | Tasks | Corrective action is tracked to closure. |
| Evidence | supports | Findings | Every finding cites what it rests on. |
| Documents | covers | Assets | Assessments (DPIA, BIA, change) record what they cover. |
| Documents | leads to | Tasks | Decisions in minutes and assessments become work. |
| Plans | schedules | Audits | The audit programme sits in the yearly calendar. |
| Plans | reviews | Risks | Risk reviews are scheduled, not remembered. |
| Plans | reviews | Assets | Asset and supplier reviews come round on time. |
| Plans | reviews | Documents | Policies are reviewed on their cycle. |
| People | holds | Roles | Staff change; accountability stays. |
| People | assigned | Tasks | Work lands with a named person. |
| Roles | owns | Risks | Every risk has someone accountable. |
| Roles | owns | Controls | Every control has someone who runs it. |
| Roles | owns | Assets | Every asset has a business and a technical owner. |
| Roles | leads | Incidents | Incident manager and responders are clear. |
| Roles | accountable for | Plans | Every programme has one accountable role. |
| Roles | defined in | Documents | Responsibilities are written down. |
GRC · Cybersecurity governance
A compliance officer and a security lead ask different questions of the same records. Neither needs a separate tool.
| Theme | GRC | Cybersecurity governance |
|---|---|---|
| Obligations | Map every clause to controls and proof. | Turn regulation into security baselines. |
| Risk | Assess, treat or accept, with an accountable owner. | Rank work by threats and vulnerabilities on real assets. |
| Assurance | Audits, findings, conclusions and evidence per clause. | Verify controls operate, continuously. |
| Accountability | Roles with decision rights, up to the management body. | Owners, on-call duty and escalation. |
| Change | Policies and registers reviewed on schedule. | Signals, incidents and vulnerabilities move risk between reviews. |
| Reporting | Board, regulator and customer questionnaires. | Exposure, incidents and remediation status. |
We can walk through any of these use cases with your requirements, risks and controls.