Risk Management #
Risk management is Deevnet’s process for handling risk: the threats and vulnerabilities that could harm its sites, its tenants or their data. Each risk is identified, assessed for how likely it is and what it would cost, and measured for the exposure it leaves. It is then given a treatment (reduced, transferred, avoided or accepted), with an owner and a record, and tracked and reviewed until it closes. Security is one kind of risk, alongside losing state, losing a device, and not being able to explain why something is configured the way it is.
Deevnet is a portable lab, run by a small team on commodity hardware with little redundancy. The aim is not to eliminate risk but to know each one, choose its treatment deliberately, and write the choice down, so nothing is a surprise.
The cycle #
| Step | What happens | Where it is written |
|---|---|---|
| Identify | a risk is noticed — in design, in a change, in an incident, from an advisory | an ADR’s consequences, a change record, an incident record |
| Assess | how likely, and how bad if it happens | the risk register |
| Treat | reduce it, transfer it, avoid it, or accept it — explicitly | a change record (reduce), an ADR (avoid/accept) |
| Review | is the treatment still right? | the register, when a related change or incident lands |
Accepting a risk is a legitimate treatment. Accepting it silently is not.
The areas #
Vulnerability Management
Tracking CVEs and advisories, checking code before production, and evaluating patches.
Security Controls
Segmentation, tenant isolation, encryption, and how credentials are held.
Exposed Credentials
What counts as an exposed credential, how soon it is rotated, and what is recorded.
Traceability
How every decision and change can be traced from why, to what, to what happened.
Resiliency & Limits
What the hardware cannot do, the risks that accepts, and what holds it together instead.
Risk Register
The known risks, how each is treated, and the record that owns it.