08 / 08 of 8
Self-control
pronounced jee-say
Domain: Change and configuration management
Every change deliberate. Every deployment reversible.
Control your actions before you control the system.
Most operational mistakes do not require malicious intent.
Someone changes a firewall rule under pressure. An administrator disables a control to solve an outage. An engineer modifies production without review. A temporary exception becomes permanent.
Change management, peer review, emergency procedures, rollback plans and privileged workflows exist because people make decisions under pressure.
Self-control is the behaviour. The process is how the organisation makes that behaviour repeatable.
The Friday hotfix nobody wrote down.
When Jisei is absent, operational pressure defeats security. Emergency changes become permanent. Temporary exclusions remain forever. Administrators accumulate privileges because removing them takes effort.
Make the behaviour explicit and repeatable.
Define change classes
Distinguish normal, standard, emergency and high-risk changes.
Establish emergency procedures
Define what can be changed during an incident and who can authorise it.
Record privileged actions
Capture administrative activity in critical environments.
Define temporary exceptions
Give temporary changes and exclusions an explicit end condition.
Establish rollback expectations
Define how high-impact changes can be reversed.
Embed the behaviour into processes and ownership.
Use just-in-time privilege
Grant elevated access for the task and remove it when the task ends.
Require peer review
Use independent review for high-impact changes where risk warrants it.
Automate expiry
Automatically remove temporary firewall rules, exclusions, privileges and exceptions where possible.
Protect emergency access
Log and restrict emergency administrative capabilities.
Use infrastructure as code
Prefer controlled, repeatable changes over undocumented manual modification.
Verify that the behaviour is happening and that it works.
Measure emergency changes
Track how often emergency procedures are used.
Measure rollback
Track changes that require rollback and identify recurring causes.
Measure standing privilege
Identify elevated access that remains active beyond operational need.
Audit temporary controls
Find expired exceptions, exclusions and temporary rules that remain active.
Review manual changes
Identify production changes performed outside approved mechanisms.
Use evidence to improve the behaviour and respond to change.
Reduce emergency demand
Use recurring emergency changes to identify weaknesses in architecture or process.
Automate controlled remediation
Where the action is predictable, make the safe response repeatable.
Improve rollback capability
Invest in reversible deployments and configuration recovery where failure has material impact.
Design for pressure
Test whether security processes still work during outages, incidents and high business pressure.
Learn from exceptions
Treat repeated emergency behaviour as evidence that the normal operating model needs to change.
An application is unavailable.
An engineer wants to open a broad firewall rule immediately.
They use the emergency-change process, restrict the rule to the required destination and schedule its removal.
Urgency does not remove the need for control.
A developer reports that EDR is slowing down a build process.
The engineer wants to disable the agent.
Instead, they create a controlled exclusion for the specific process and review the resulting telemetry.
Fix the conflict without removing the control from the entire system.
An engineer needs domain-level privileges during an outage.
They use JIT elevation for the duration of the intervention.
The privilege disappears automatically afterward.
Give yourself the power required for the task, for the time required by the task.
A developer discovers that a production deployment is failing.
They have sufficient permissions to modify the infrastructure manually.
They resist making an undocumented change directly in production and correct the infrastructure-as-code deployment instead.
A quick fix can create a second incident that nobody knows how to reproduce.
A project team wants to bypass a security control because the implementation deadline is approaching.
They request an exception with an owner, expiry date and compensating control.
The exception is reviewed after the release.
Control the exception before the exception controls the environment.
Reading: Jisei is the modern eighth virtue, and the fact that the most process-heavy security domain maps to the least classical virtue is worth one honest sentence rather than a silence.
| Control | Control title | Strength | Why it maps |
|---|---|---|---|
| PR.PS-01 | Configuration management practices established | direct | Configuration management practice is self-control expressed as infrastructure — deliberate, recorded change. |
| ID.IM-03 | Improvements from operational processes | partial | Improvements drawn from operations feed the discipline but are a step removed from the change act itself. |
| Control | Control title | Strength | Why it maps |
|---|---|---|---|
| A.8.32 | Change management | direct | Change management is the virtue's core: every change deliberate, every deployment reversible. |
| A.8.9 | Configuration management | direct | Configuration management keeps the known-good state defined and enforced. |
| A.8.31 | Separation of development, test and production environments | direct | Separating development, test and production is the restraint not to change production directly. |
| A.8.33 | Test information | partial | Controlling test information supports safe change but sits at the edge of the domain. |
The classical enumeration of Bushido is seven virtues: Gi, Yū, Jin, Rei, Makoto, Meiyo, and Chūgi. Self-control (自制 jisei, more commonly 克己 kokki) is a twentieth-century addition, largely downstream of Nitobe Inazō's 1900 book Bushido: The Soul of Japan, which framed samurai ethics for a Western readership. This site keeps eight because self-control maps to something real — change and configuration management — but it says so plainly rather than hiding the seam.