Why I built it
Most governance tools stop at a checklist: a control is ticked, and nothing connects that tick to the obligation behind it, to the evidence that would prove it, or to the risk it is supposed to reduce. I wanted to see whether the whole chain could be kept in one place and kept honest: an obligation, the control that answers it, the evidence collected on that control, the finding when the evidence fails, the risk that follows, and the decision someone signs.
Kontrol is that attempt: a web application I wrote in TypeScript, with a management-system module for ISO/IEC 27001, a risk register, a multi-framework compliance hub and an append-only audit log in which every change is chained to the previous one. This page shows it on a complete case rather than describing its features.
The case: Hydria, a fictional water utility
Hydria does not exist. Its name, figures and people are invented, and nothing here comes from an organisation I worked in. I chose a water utility because it combines what makes governance difficult: an essential service, personal data at scale, an industrial network next to the office network, and a security operations centre that uses AI-assisted triage.
| Item | Detail |
|---|---|
| Activity | Drinking-water supply and billing for about 410,000 customers |
| Scope of the management system | The Security Operations Centre service and the customer information system |
| Excluded, with a reason | The industrial control systems themselves (only their one-way log interface is in scope), the customer agencies, the subsidiaries |
| Frameworks adopted | ISO/IEC 27001:2022 for the management system, ISO/IEC 42001:2023 for the AI triage pipeline, Moroccan Law 05-20 (cybersecurity) and Law 09-08 (personal data) |
| Legal context | Law 05-20 on cybersecurity and Law 09-08 on personal data are followed article by article, each article linked to the controls that answer it. Hydria scores 47 % on the first and 27 % on the second |
The dossier, in three steps
Three scripts load the dossier through the application's public interface, so every record goes through the same checks and the same audit log as if a person had typed it. Run from an empty database, they end in the same state every time.
1. Foundation
Eight internal and external issues; seven interested parties, each with what it requires; a scope statement with its boundaries and three justified exclusions; a one-page security policy; five objectives, each with a measure, a target, an owner and a date. One commitment of the policy carries over from my internship project: automated analysis, including AI, may propose, and a named person decides.
2. Risk assessment and treatment
An approved method: a five-by-five matrix, with what each impact level means for confidentiality, for integrity and for availability, and a risk appetite set at medium. Eight assets valued on those three properties. Fifteen scenarios, each built from an asset and a threat, so that a scenario's impact cannot exceed the value of the asset it concerns. The state and the owner of 44 controls. A treatment plan, an owner and a date for every risk that is mitigated.
3. The system in operation
Signed reports from the learning and HR systems; a first measurement of each objective; a phishing incident handled to its lessons; two nonconformities; the internal audit programme; the first management review, with its decisions turned into tasks.
The result
What the dossier shows, including what is not finished
A dossier where everything is green teaches nothing and convinces nobody. I built this one to look like a management system in its first year.
- Eleven of fifteen risks stay above the appetite. Most controls are partial or planned, so the residual rating hardly moves. Kontrol computes it from the state of the controls; I cannot improve it by typing a lower number.
- One risk is accepted above the appetite, for six months, by the managing director, who neither owns nor recorded it, with the reason on record. The application refuses the acceptance from anyone else.
- A control is left failing. The HR report says two leavers kept an account after their departure. The claim on identity lifecycle is then capped, and the report lists it as a contradiction between what is attested and what is observed.
- The incident produced a nonconformity: MFA was not enforced on ordinary accounts. Its corrective action is open and on time. A second nonconformity went through the whole cycle and was closed by someone other than the owner of the action.
- Clause 9.2 is partial on purpose. The internal auditor is not trained yet, so the first audit is planned and none is completed. The checklist says exactly that.
Rules the application enforces
| Rule | Why it matters |
|---|---|
| The person who owns or recorded a risk cannot accept it | Separation of duties is checked by the system, not left to a procedure |
| An acceptance expires, and a critical residual risk cannot be accepted | An accepted risk does not quietly become permanent |
| Failing evidence caps an attested control at partial | A declaration cannot outrank an observation |
| A corrective action is verified by someone other than its owner | Closing one's own finding proves nothing |
| A clause with no record is missing, not met | A process that has never run is not shown to work |
| Every change is appended to a hash-chained audit log | Removing or altering an entry breaks every hash after it |
What using it taught me about my own tool
Until I tried to run a complete case, Kontrol had only seen its own sample data. The dossier found what the tests had not:
- No asset could be entered by hand. Only connectors created assets, so a service or a supplier could never be valued or assessed. Asset entry and retirement are now part of the risk register.
- Steps needing two people could not be demonstrated, and the organisation kept the name of the sample data in every export.
- The report described its signature wrongly: it printed an Ed25519 signature and explained it as an HMAC. Reading my own PDF as an auditor would is what found it.
- The claims and the records disagreed. The clause on communication was met by its records while the matching control was still marked not started. Reconciling the two is exactly the work a statement of applicability asks for.
- Moroccan law was missing. The two national laws could only be noted as requirements of interested parties. I wrote a catalogue for each from the official French texts, 18 articles apiece, and mapped every article to the unified controls. Hydria now has a statement of applicability for each law.
Limits
- Nothing here was audited. Readiness levels, clause checks and capability levels are my design choices; no certification audit has confirmed them. They are a structured self-assessment, not a prediction of an audit result.
- The calendar is compressed. Every record is created the day the scripts run. A real management system takes months to produce measurements, an incident, corrective actions and a review.
- The ratings are plausible, not measured. Likelihoods, asset values and control states were chosen for a believable operator.
- Collectors are only partly proven. The GitHub collector has been run against a real repository of mine; the AWS and Okta collectors have only been tested against simulated services.
- The legal mapping is mine. The links between the articles of the Moroccan laws and the controls are my reading, not a published source; the implementing decrees are outside the catalogues, and treating Hydria as an infrastructure of vital importance is an assumption.
The source is public: github.com/omarbabba779xx/kontrol. The dossier, its three loading scripts and its exports (statements of applicability, risk treatment plan, signed report) are in examples/hydria.