DEV Community: Manfredi Marrocco

Fallout: Who Can Accept the Risk of a Vault?

Manfredi Marrocco — Sun, 08 Nov 2026 17:00:00 +0000

The shelter promises to remove uncertainty from the world. Outside, there's radiation and violence; inside, a massive door, precise rules and an organization that claims to have foreseen everything. In Fallout, the promise of Vault-Tec is inseparable from the question of who controls the terms of the pact. For risk management, this is precisely the crucial question: who can accept a risk, on whose behalf, and with what information?

The following scene is fictional. In the vault room, the ventilation manager places two ledgers on the table. One shows the month's savings; the other shows the postponed interventions. The supervisor reads only the first. "The system is working," he says, while behind the wall, a fan changes its noise. A technician asks who verified the alternative air-circulation route. No one answers. The risk hasn't gotten any smaller: it's just disappeared from the presentation.

The technician is not asking for the shelter to close. She asks for evidence, a named decision-maker and a condition that would trigger a stop. This is where metaphor meets risk management: separating the decision maker's benefit from the consequences for those who depend on the service. Even a temporary choice must explain what will happen if its core hypothesis ceases to be true.

Before the risk comes the goal

ISO 31000 offers guidelines for integrating risk management into decision-making. It's not certification that an organization is safe. The approach considers risk in relation to objectives: it's therefore necessary to clarify what you want to protect or achieve before cataloging negative events.

For a delivery service, the goal might be to complete orders within the agreed-upon deadlines. The risk scenario becomes: a breakdown in the sorting system prevents shipments from being prepared, resulting in delays and costs. "The server" is a resource; "the breakdown" is an event; "failure to deliver" is a consequence for the objectives. Mixing them prevents comparing alternatives.

In the Vault, protecting the lives of its inhabitants and maximizing the duration of an experiment would be profoundly different goals. The metaphor makes visible a conflict that a risk sheet shouldn't hide.

Appetite and tolerance must become decisions

In management jargon, risk appetite indicates the type and amount of risk an organization intends to assume to pursue its objectives. Risk tolerance translates this approach into operating limits and permissible variations. The definitions adopted must be made explicit: simply using English terms is not enough to achieve shared criteria.

"Low tolerance for disruption" is too vague. A usable criterion distinguishes duration, services involved, exposed people, and recovery possibilities. Some constraints arise from law or contracts and are not freely negotiable. Management cannot eliminate them by declaring a high appetite for risk.

Furthermore, when it comes to risks to human safety, a simple economic comparison may be insufficient. Relevant expertise, assessments, and accountability are required. Vault-Tec isn't a governance model to imitate: it's a way to question the distance between those who decide and those who suffer.

Evaluate before choosing

A usable assessment describes the scenario, causes, existing controls, probabilities, and consequences, along with uncertainties. The risk owner, responsible for risk management, involves those familiar with the process; security verifies the technical aspects; the decision maker has the authority to commit resources or authorize exceptions.

Considering an inherent risk can help describe exposure before controls, as long as the method specifies what it ideally removes. Residual risk is the risk that remains after considering the measures actually in place. The risk expected after a project yet to be implemented must be identified separately: it has not already been reduced.

Comparison helps you choose. You can avoid the activity, modify the probability or consequences, share some consequences through contracts or insurance, or knowingly maintain the exposure. Transferring part of the cost does not automatically transfer liability, personal injury, or obligations.

A documented, entirely hypothetical decision-making example

A logistics company uses an out-of-support platform to coordinate shipments. The migration requires a downtime window during a busy period. The operations manager must choose between immediate replacement, controlled postponement, and suspension of part of the service.

The proposed decision sheet records:

Field	Content of the hypothetical case
Scenario	Compromise of the legacy server, stopping order dispatch
Evidence	Support ended, access rights inventoried, recovery testing not yet complete
Options	Immediate migration; thirty-day postponement with compensating controls; temporary reduction in service
Decision	A limited postponement, conditional on segmentation, restricted access and a recovery test
Responsible person	Operations Director according to internal delegations
Review	Within thirty days, or immediately in the case of known relevant exploitation
Residual	Unpatchable vulnerabilities and uncertainty about recovery time remain

The thirty days are an organizational assumption, not a deadline established by ISO 31000. The document makes the decision reconstructable; it doesn't prove its automatic acceptance.

The IT manager must produce the results of the compensating controls. If segmentation isn't implementable or recovery fails, the basis for the decision changes: the same risk level isn't maintained for convenience.

Acceptance has conditions and a deadline

An unconditional signature can become a permanent proxy for inaction. A useful decision specifies the rationale, scope, duration, necessary controls, escalation triggers, and monitoring methods. It must also specify who will replace the absent decision-maker.

Not every risk requires a board of directors. Thresholds consistent with the mandates are needed: the service owner can manage some deviations; risks beyond the thresholds or with cross-functional consequences must be escalated to the appropriate level. The consultant supports the analysis, but does not implicitly accept the risk on the client's behalf.

A subsequent review must verify the conditions, not simply update the report date. New vulnerabilities, changes in volume, or loss of expertise can invalidate the initial assumption even before the deadline.

Mistakes to avoid

Mistaking the absence of incidents for low probability means using the past as a guarantee. Assigning a precise number without data creates a false sense of security. Considering a risk "green" because it has been accepted confuses the authorization process with exposure reduction.

Another mistake is to present the choice as binary: upgrade now or do nothing. There are temporary exposure reductions, service limits, workarounds, and migration sequences. Their value depends on feasibility and evidence, not on the number of boxes checked.

Three questions before closing the door

Who has the authority to accept this exposure and who will suffer the consequences?
What evidence supports the residual assessment, and what conditions are not yet met?
What event or date will force us to reconsider our decision?

Fallout exaggerates the asymmetry between organization and inhabitants. A real company isn't a Vault, and risk management doesn't authorize experiments on unsuspecting people. The limit of the analogy is also its lesson: a choice doesn't become responsible just because someone wrote that the risk was accepted.

Related insights

To connect acceptance to the cost of not upgrading and the GRC framework: When Upgrading Is Heresy: Warhammer 40K and Legacy Systems Risk; What GRC Means: Governance, Risk, and Compliance Without the Jargon.

Essential sources

English adaptation of my original article on manfredimarrocco.blog. The blog remains my primary editorial source. Original illustrations are reused from the blog. Translation and adaptation assisted by AI.

When Updating Is Heresy: Warhammer 40K and the Risk of Legacy Systems

Manfredi Marrocco — Sun, 01 Nov 2026 17:00:00 +0000

The Adeptus Mechanicus, technical debt and the price of technology nobody dares to change.

In the name of the Machine God

Imagine a forge world. The cathedral houses a machine rather than an altar. Walkways disappear into smoke; pipes climb iron walls like ribs. Candles tremble beneath the gears. Somewhere above, an indicator keeps blinking.

A tech-priest approaches a panel, performs an inherited sequence and waits. The machine answers. Nobody remembers who wrote the original instructions. Nobody wants to discover, in front of an idle factory, why the seventh step could not be skipped.

This is an imagined scene, not a canonical story. But its paradox fits Warhammer 40,000: a civilisation depends on technology that is as important as it is difficult to understand, change or replace.

Remove the robes, lower the chanting and replace the sacred panel with the server nobody has dared restart since 2014. The comparison becomes less strange.

Act I — The cult of the machine

Warhammer Community's introduction to the Adeptus Mechanicus describes engineer-priests preserving, reproducing and maintaining ancient technologies, some only partially understood. Knowledge, devotion and maintenance are intertwined.

It would be inaccurate to reduce them to “they hate everything new.” The Mechanicus also searches for lost knowledge, and Belisarius Cawl is an obvious counterexample to complete technological immobility.

The useful question is different: how much room remains for change when the explanation of a technology's operation is wrapped in the authority of tradition?

In our imaginary cathedral, an apprentice asks why a lever must be pulled twice. “We have always done it that way.” There may be an excellent reason. It may also be a workaround for a fault fixed centuries ago. Nobody can distinguish the two.

In IT, the ritual looks less solemn: a file named FINAL_v7, a procedure stored in one person's memory, or an application that only works with one particular library version. The system still produces results. The ability to explain those results is diminishing.

A technology can keep working after the organisation has lost much of its ability to govern it.

An inventory therefore needs more than a server name. Who owns it? Which process depends on it? What data does it handle? What does it depend on? Who knows how to restore it?

If the custodian leaves and the explanation leaves with them, the organisation loses more than a person. It loses part of its operational capability.

Act II — The cost of standing still

The machine keeps running. Everyone is reassured until a spare part disappears, an interface changes or vendor support ends. The temple discovers its stability had an expiry date. Nobody put it on the calendar.

Technical debt resembles interest on a deferred decision: a shortcut or unsuitable solution makes later work more expensive. It is not simply another word for age. Fear of touching a system can feed it: the less we know, the less we change; the less we change, the harder recovering knowledge becomes.

Consider a wholly hypothetical shipping application. It is reliable, but runs on an unsupported operating system and depends on a component the new environment rejects. Migrating during the seasonal peak could stop the warehouse. A short postponement may be reasonable.

Postponing for five years without review is different. Threats, access and staff change. Supplier knowledge becomes concentrated in one technician approaching retirement. The machine has not become sacred; it has become difficult to replace.

Joint CISA/NSA guidance on risky configurations highlights unsupported software and hardware: vulnerabilities may remain without vendor fixes. But “legacy” does not automatically mean vulnerable or non-compliant. Support, exposure, data, threats and actual controls matter.

In our warehouse, the postponement needs an owner and a review date. Meanwhile, necessary communications can be restricted, the system separated from less trusted networks, unusual activity monitored and authorised accounts reduced.

These are compensating measures to evaluate and test, not a blessing that removes every vulnerability. Guarding a door does not repair the wall. It may reduce exposure while the repair is prepared.

Delaying an update can be necessary. Systematically ignoring the resulting risk is something else. Incense is unfortunately not a compensating control.

Act III — The necessary heresy

Now the innovator arrives, looks at the panel and proposes replacing everything on Friday afternoon. Two hours later, the main machine runs perfectly. Three connected production lines are waiting for a signal the new system no longer sends.

The priests feared change. The newcomer feared only slowness. Both ignored the same thing: dependencies. A patch applied without understanding them can compromise availability while trying to improve security.

NIST SP 800-40 Rev. 4 treats patch management as preventive maintenance and an organisational process: identifying, prioritising, acquiring, installing and verifying updates. Security needs must be connected with the needs of the people keeping services running.

For the warehouse, change starts before the maintenance window. Reconstruct integrations, agree an acceptable interruption and test the new environment. Test the whole process: the order enters, the shipment leaves and the data returns correctly. An application opening successfully does not prove the service works.

Then prepare the way back: verified backups, workable instructions, available people and criteria for stopping. Rollback is not the sentence “we can always go back.” Some data changes make it complicated. Understand that before the warehouse phone starts ringing.

Postponement also needs governance:

What residual risk remains?
Who accepts the decision?
When will it be reviewed?
What event would require earlier action?

The cautious custodian and the innovator can sit at the same table. One knows the machine's scars. The other sees another route. Neither should win by principle. They need a transition the organisation can sustain.

Prayer is not a recovery strategy

Not every old technology needs scrapping. Not every new one deserves trust. A well-understood, maintained system may be more valuable than a brilliant replacement whose dependencies nobody has analysed.

But continuity cannot depend indefinitely on luck or the last remaining custodian.

Perhaps the real heresy is not updating. It is continuing to call something prudence after we can no longer explain it.

What would be harder in your environment: replacing the oldest system, or reconstructing the knowledge needed to change it safely?

English adaptation of my original article on manfredimarrocco.blog, my primary editorial source. The forge-world scenes are illustrative inventions, not quotations from Warhammer fiction or descriptions of client systems. Illustrations come from the original article. Translation and adaptation assisted by AI.

The Wall Has Fallen. What Is Your Cybersecurity Plan B?

Manfredi Marrocco — Sun, 25 Oct 2026 17:00:00 +0000

Game of Thrones, NIS2 and the illusion of absolute security.

Spoilers for season 7 of the television series. The illustrations are original, not frames from the show.

The wall at the end of the world

The North. The cold. A stretch of snow where even sound seems frozen. At the edge of the landscape stands the Wall: so enormous that its defenders appear insignificant.

On its towers, the Night's Watch studies the horizon. Farther south, the powerful mostly study one another. Alliances must be broken, land conquered and a crown protected. The end of the world is distant. Distant problems can wait.

The Wall is still standing. It divides the known world from what nobody wants to know. Looking at it is enough to feel on the safe side of danger. But reassurance is not a property of ice. It is something people attribute to it.

The structure becomes a silent promise: whatever moves beyond the border, someone else will handle it. That promise makes it comfortable to govern without asking what that comfort costs.

Then comes the question every fortification should keep alive: what happens when the defence on which you built your security stops existing?

Act I — The Wall is not a strategy

The Wall is not useless. It is extraordinary: a boundary, an observation point and a defensive advantage. The mistake is treating it as a sufficient answer to every question.

Visible defences are easy to love. You can point to them on a map and measure their height. Asking whether the sentries have enough people, information and support is less spectacular.

A fortress also depends on supplies, communication, maintenance and people who can interpret an alarm. Those dependencies can weaken while its stones still look perfect. Fragility does not always leave a photogenic crack.

In the season 7 finale, the Night King attacks near Eastwatch with the resurrected Viserion. Blue fire brings down a section of the Wall. The army of the dead crosses the breach. Not every metre disappears; the assumption that it is impassable does.

The threat has not respected the form its defenders expected. A control designed around one threat can lose effectiveness when an adversary's capabilities change. Continuing to stare at the wall does not update the world in front of it.

In cybersecurity, risk assessment challenges assumptions: which services do we protect, what do they depend on, what vulnerabilities remain, and what happens when a control fails? Layered defences can limit propagation, but do not guarantee invulnerability.

For entities within its scope, NIS2 Article 21 requires appropriate and proportionate technical, operational and organisational measures. Its coverage includes risk analysis, vulnerability handling and supply-chain security. It does not prescribe one universal perimeter architecture.

An impressive measure does not replace a risk-management process.

Act II — No one listens to the North

The next problem is not on the Wall. It is in the rooms where people decide whether events on the Wall deserve attention.

Imagine a warning travelling through snow, past tired horses, into a warm hall. Before becoming a decision, it must cross a terrain more difficult than the forest: the recipients' pride.

Who sent it? Who benefits? Would admitting the threat mean cooperating with yesterday's enemy? Who would exploit a weakened southern defence? A shared danger enters the room; private interests ask it to wait outside.

Jon seeks support against the dead. Cersei sees evidence at King's Landing, promises help and later reveals that she does not intend to honour the commitment. Knowing about the danger does not erase political calculation.

This is not simply a lack of information. It is a decision to interpret information through immediate convenience. The rival beside the throne has a face and an ambition. The distant threat can wait until the next meeting.

The Watch can observe and warn. It cannot force every court to mobilise resources. Detection does not automatically provide the authority to act.

An organisational alert follows a similar route: detection, communication, escalation and decision. Without clear responsibilities, a message can circulate without becoming action. Risk governance connects those steps to people, priorities and resources.

NIS2 Article 20 addresses approval and oversight of cybersecurity risk-management measures by the management bodies of essential and important entities, alongside accountability and training within the applicable framework. Westerosi rulers are a metaphor for decision-making, not legal equivalents of management bodies.

A known risk is not automatically a managed risk. The raven has arrived. What happens after someone opens the message?

Act III — After the Wall falls

When the ice gives way, the map changes before anyone can redraw it. A boundary becomes a route. The distance that appeared to protect the continent begins to disappear.

Pause there, before the next battle. “The Wall holds” used to be a reassuring answer. It is no longer useful. Forces must be positioned, warnings delivered and usable roads identified. Surprise does not grant a pause to organise.

The useful plan B is not necessarily another identical wall. It is a network capable of moving: messengers with clear destinations, supplies with more than one route, assembly points and instructions that still work when the expected commander cannot be reached.

These are questions raised by the breach, not events I am attributing to the screenplay. A kingdom may survive losing a fortification. It is harder to survive without knowing who should do what.

Containing an attack and maintaining priority activities are related but distinct tasks. Disaster recovery concerns technological recovery. Business continuity also covers people, processes, communication and dependencies. An alternative is real when it can be used, not merely when it appears in a document.

NIS2 Article 21(2)(b) and (c) includes incident handling, business continuity, backup management, disaster recovery and crisis management. The principle is to prepare the response as well as the defence. A fantasy collapse is not a cyber incident; it makes the cost of relying on one defence visible.

Exercises can expose unreachable contacts, forgotten dependencies and incompatible priorities before a crisis. Less cinematic than a dragon, certainly. But knowing where to go can separate an organised retreat from a crowd running without direction.

When the North is no longer distant

Westeros becomes fragile before the ice falls: whenever the border becomes a reason not to listen, rivalry outranks a shared threat, or the future is entrusted to one defence remaining in place.

The Wall could buy time. It could not decide how that time should be used. That is the distance between cybersecurity made of objects and cybersecurity made of responsibilities: protect, understand, decide and prepare.

If your strongest control failed tomorrow, who would make the first three decisions? Have you tested that handover?

English adaptation of my original article on manfredimarrocco.blog. The blog remains my primary editorial source. Illustrations are reused from the original. Translation and adaptation assisted by AI.

Sources: Directive (EU) 2022/2555, Articles 20–21; Game of Thrones, season 7, episode 7, “The Dragon and the Wolf” (narrative reference: ABC News).

The Palantír Does Not Lie. But Who Controls What You See?

Manfredi Marrocco — Sun, 18 Oct 2026 07:39:13 +0000

Three cybersecurity lessons from Middle-earth: trust, concentrated power and resilience.

A tower. A silent chamber. A dark stone lights up with armies, cities and distant fires. Whoever watches it has something irresistible: the feeling of seeing what others cannot see.

It looks like an absolute advantage. Then comes the uncomfortable question: are you understanding the world, or is someone deciding which part of it you get to see?

The Palantír is a surprisingly modern temptation. It promises visibility and puts information in front of decision-makers. A security dashboard does something similar, although it usually does not contain the Eye of Sauron. Usually.

The Lord of the Rings is not a cybersecurity manual. But three of its images help us ask better questions: a stone that shows, a ring that concentrates power, and a fellowship that must keep moving when its original plan breaks.

The Palantír: seeing is not understanding

In Tolkien's books, the seeing-stones are not simply screens displaying fabricated footage. Their danger also involves the people using them, other observers and the interpretation of what is seen.

Saruman becomes entangled with Sauron. Denethor is not merely his puppet: he resists Sauron's will, but the partial knowledge obtained through the stone contributes to his despair. Reducing both stories to “they believed a fake video” misses the point.

An authentic scene can still support a wrong conclusion. You do not need to invent an enemy army if showing that army, while leaving other possibilities outside the frame, is enough.

The truth of what you see does not guarantee the completeness of what you know.

Monitoring collects signals. Threat intelligence adds context to threats. Neither makes the final decision infallible. Coverage, source reliability, freshness and missing information still matter.

Consider a hypothetical organisation whose dashboard reports very few unusual login attempts. Excellent news? Perhaps. Or a critical system stopped sending logs three days ago. The number is accurate for the data received; the conclusion “we are safe” is not.

Before celebrating, ask which systems are covered, whether the sensors work and whether the events have been checked against other evidence. A green indicator is not a certificate of invulnerability.

The NIST Cybersecurity Framework 2.0 connects adverse-event analysis with correlating information and understanding impact. The practical lesson is to verify the signal, reconstruct its context and separate observation from interpretation.

GRC decoder: turn the metaphor into a control

Risk: few alerts appear reassuring, but an important source may have stopped reporting.
Control practice: inventory expected log sources, check continuity and completeness, and compare findings with other evidence.
Evidence: source inventory, last-ingestion timestamps, missing-source alerts and documented reviews with an owner and date.
Operational question: who is notified when a system stops sending logs, and what proves that notification works?

This is an illustrative example. Control selection depends on context; implementing it alone does not establish conformity with a standard.

The One Ring: concentrated power becomes a risk

One Ring to rule them all.
— J.R.R. Tolkien, The Lord of the Rings

The Ring-verse promises domination, rather than coordination or well-documented delegation.

Part of its appeal is the temptation to use it for a good cause. The problem is not solved by choosing a well-intentioned person. Concentrated power changes the risk, and believing you can master it is part of the trap.

The Ring is not literally an administrator account. The analogy concerns concentration: one identity able to change systems, manage users, access sensitive data and disable controls can cause extensive harm if compromised or misused.

Privileged access is necessary. It needs governance. Least privilege grants only the access needed for a function. Privileged access management governs privileged access; it is not a spell that makes every administrator safe.

Imagine a technician who needs one hour to correct a configuration. Permanent privileges across every environment “just in case” turn a limited need into continuous exposure. Limits on scope and duration, appropriate approvals and activity records reduce that gap.

Separation of duties also helps prevent every sensitive decision depending on the same identity. The requester, approver and reviewer do not always need to be the same person. The practical arrangement depends on risk and organisational structure.

CSF 2.0 outcome PR.AA-05 connects permissions management and review with least privilege and separation of duties. It describes an outcome, without prescribing one specific product.

In language that does not require a council of Elrond: do not hand out little Rings of Power for convenience and hope nobody finds the password.

The Fellowship: continue when the plan breaks

The Fellowship begins with a common objective, not nine interchangeable people. Different skills and responsibilities complement one another. That does not eliminate conflict or guarantee an orderly journey.

At the end of The Fellowship of the Ring, the group separates and Frodo continues with Sam. Cooperation no longer means everyone remaining in the same place. It means acting differently without losing the mission.

This is where the metaphor meets business continuity. The question is not only “do we have a plan?” It is “can we maintain priority activities when people, technology or suppliers become unavailable?”

A plan that works only if one person answers the phone is fragile. So is a service dependent on one supplier without realistic alternatives, or a procedure known only to its author. These can become single points of failure.

In another hypothetical scenario, the service owner cannot be reached during an incident. Without known priorities, delegated authority and contact details, the first response becomes a search for someone who knows what to do. Preparation makes that information and practical substitutes available before the emergency.

NIST contingency-planning guidance connects impact analysis, recovery strategies and exercises with system preparedness. NIST SP 800-61 Rev. 3 places preparation, detection, response and recovery within cybersecurity risk management.

Keeping a document is not enough. People and resources must be able to perform the actions, including in degraded conditions. Exercises expose optimistic assumptions before an incident does.

Middle-earth is not an enterprise architecture to copy. Its mission retains decisive dependencies, and its characters are not boxes on an organisation chart. But it offers a useful question: can your organisation change route when the expected road disappears?

Three images, one governance question

The Palantír asks us to examine information in context. The Ring exposes the risk of concentrated power. The Fellowship reminds us that preparation matters when the route stops being straightforward.

Before consulting the stone, ask who controls the view. Before granting the Ring, ask who controls the power. Before setting out, ask what the Fellowship will do when the road disappears.

Which would expose the bigger gap in your environment today: a missing log source, an overpowered account or an unavailable service owner?

English adaptation of my original article on manfredimarrocco.blog, the primary source for my articles and projects. Illustrations are reused from that article. Translation and adaptation assisted by AI.

Literary references: Tolkien's The Two Towers (“The Palantír”), The Return of the King (“The Pyre of Denethor”), The Fellowship of the Ring (“The Breaking of the Fellowship”) and Unfinished Tales (“The Palantíri”). These metaphors refer to the books.