Summary

  • RIPE NCC's 2025 plan assigned EUR 3 million to Information Security, Risk and Compliance, including EUR 880,000 of consultancy and EUR 860,000 of information-technology expense. It set objectives including continuous monitoring, identity governance, privileged-access management, a governance-risk-compliance platform, ISO 27001 work and RPKI assurance. These are material, intelligible control investments; the published plan does not amount to a threat model linking adversaries and attack paths to residual risk.
  • A regional Internet registry has an unusual attack surface. It combines ordinary corporate systems with membership identity, authoritative registration data, delegated administrative power, RPKI services, DNS infrastructure, policy records and relationships with thousands of network operators. The gravest event may be an authenticated but illegitimate change, not a spectacular outage.
  • A service-criticality table is useful but incomplete. RIPE NCC publicly rates the confidentiality, integrity and availability of eight services, placing very high integrity and availability requirements on RPKI and very high integrity requirements on the RIPE Database. Criticality describes the consequence of failure; a threat model must also identify capable actors, preconditions, dependencies, control assumptions and plausible sequences to that failure.
  • Independence does not require an outsider to invent the model and does not justify publishing exploitable detail. Management and engineers should build the operating model. A Board committee, or an expert retained by and reporting to it, should challenge scope, assumptions, vendor incentives, excluded scenarios and the evidence used to declare residual risk acceptable.
  • Security certification, penetration testing, vulnerability counts and monitoring coverage answer different questions. None shows on its own that spending is allocated to the most consequential registry attack paths. A compliant control can be operating while a dangerous identity, supplier, legal-authority or recovery assumption remains outside the assessment boundary.
  • Members should receive a safe threat-model abstract with protected technical annexes. The public record should state critical powers and services, adversary classes, principal dependency and concentration risks, impact ranges, risk appetite, funded mitigations, residual-risk owners, assurance method and the Board decision. That would let members test budget direction without giving attackers a map.

A security budget is an allocation of belief

Every security purchase contains a belief about the future. A managed detection contract assumes that faster observation and response will reduce loss. Privileged-access software assumes that powerful credentials are a central route to harm. A governance-risk-compliance platform assumes that obligations and controls are difficult to track consistently. A certification programme assumes that disciplined management and external assurance will improve trust. A second data centre assumes that interruption is plausible enough to justify duplication. Training assumes that staff behaviour is a material exposure.

Those beliefs may all be reasonable. The governance problem begins when they remain implicit. A Board presented with a list of reputable products, urgent vulnerabilities and compliance deadlines can approve each line while never deciding which institutional catastrophe is most important to prevent. The resulting programme can be busy, expensive and professionally managed yet still be assembled from vendor categories rather than registry consequences.

This matters because security spending has no natural ceiling. There is always another alert source, audit, consultant, access product, intelligence feed, backup, exercise or certification. It is difficult for a non-technical director to reject a proposal described as necessary protection for critical infrastructure. A successful year produces no visible counterfactual: the absence of a breach can be evidence of effective controls, luck, quiet attacker presence or an exaggerated threat. The budget therefore tends to accumulate unless the institution can say what risk a line reduces and what evidence would change the decision.

A threat model is the missing allocation document. It need not predict named attackers or assign a precise probability to every scenario. It should identify assets and powers that matter, actors with motives and capabilities, trust boundaries, dependencies, likely paths, failure consequences and existing defences. It should show where evidence is strong, where judgment substitutes for data and which residual risks the Board accepts.

The public record does not establish that any named RIR lacks internal threat analysis. Security teams ordinarily keep sensitive models, architecture and test results restricted. The narrower finding is that published spending and control commitments do not let members determine whether an independently challenged model governs the allocation. That is a disclosure and oversight gap, not proof of technical negligence.

A registry is not merely another medium-sized enterprise

An RIR has payroll, email, laptops, human-resources records and finance systems like many other non-profits. It must defend against ransomware, invoice fraud, credential theft, vulnerable software and malicious insiders. Conventional enterprise controls are necessary. They are not sufficient to describe the institution's distinctive authority.

The registry maintains records connecting organizations to Internet number resources. It operates portals through which authorized contacts request and manage services. It publishes or supports authoritative data used by network operators, researchers, law enforcement, security teams and commercial services. It may issue and host RPKI material that helps operators validate route-origin assertions. It operates or contributes to DNS and measurement services. It carries institutional records about policy, membership, elections and fees.

Its staff make consequential judgments about documentation, transfers, account control, compliance and closure.

This creates several forms of harm. Confidential member data can be exposed. Registry data can be altered. A legitimate holder can lose account control. A false organization or contact can gain authority. A resource record can be changed in a way that supports hijacking or fraud. A certificate or authorization can be wrongly issued, revoked or withheld. A service can become unavailable during a routing incident precisely when operators need it. A supplier can retain excessive access. A technically correct action can be taken on a fraudulent instruction.

An operational decision can be lawful but poorly governed and then defended as a security necessity.

Availability is only one dimension. The most dangerous attack may leave every dashboard green. If an adversary obtains a valid credential and makes a plausible change through an approved interface, the system can process the action normally. If a compromised vendor account modifies infrastructure through an authorized maintenance path, monitoring may record a legitimate identity doing an authorized operation. If staff accept a forged corporate document during a resource transfer, the weakness sits at the border between legal verification, identity and technology.

The model must therefore begin with registry powers, not devices. It should ask who can change which fact, grant which authority, sign which entity, approve which transfer, suppress which evidence, restore which service and override which control. Only then can tools be evaluated against the real loss.

The published RIPE NCC spend shows controls, not the threat argument

The RIPE NCC 2025 Activity Plan and Budget allocated EUR 3 million to Information Security, Risk and Compliance, a 50 percent increase from the comparison baseline in the plan. The activity listed nine full-time-equivalent positions, EUR 880,000 of consultancy and EUR 860,000 of information-technology expense. Its stated work included an ISAE 3000/SOC 2 Type 2 assurance report for RPKI, ISO 27001 compliance, a control-monitoring programme, a governance-risk-compliance platform, expanded awareness, vulnerability dashboards, Identity Governance and Administration, Privileged Access Management, around-the-clock monitoring and stronger application security.

These are unusually concrete budget disclosures. Members can see more than a single organization-wide cyber line. They can identify staffing, consultancy, software and a list of commitments. A separate explanation of the plan said EUR 900,000 of additional operating expense supported the security focus, with EUR 400,000 for software and EUR 500,000 potentially used for consultants or recruitment where qualified staff were difficult to hire.

The 2026 Activity Plan and Budget continues the compliance and resilience direction. It describes an ISO 27001 certification audit, recurring RPKI assurance, cloud-related continuity work and operation of the risk and compliance platform. The trajectory is understandable: build a managed system, prove controls, monitor continuously and reduce reliance on fragile or informal practice.

What these publications do not show is the causal hierarchy behind the portfolio. They do not tell members whether account takeover outranks software supply-chain compromise; whether a repository-integrity event outranks a two-day portal outage; whether insider collusion, fraudulent corporate documents, state coercion or cloud concentration received independent challenge; or which accepted risk remained after the funded controls. The activity descriptions explain what the institution intends to do. They do not expose the decision rule used to prefer one mitigation over another.

That distinction should not diminish the programme. A public budget cannot contain credentials, architecture diagrams, known weaknesses or attack simulations. But it can safely state the high-level scenarios being reduced, the accountable owner, the evidence used, the expected risk movement and the assurance that will test it. Without that bridge, a member can verify expenditure and activity, but not priority.

Control catalogues cannot substitute for attack paths

ISO 27001, SOC-style assurance, the NIST Cybersecurity Framework and internal policy catalogues organize security work. They help an institution assign responsibility, assess controls, maintain evidence and improve repeatability. Their value is especially clear in an organization with varied services and suppliers. A control that exists only in one engineer's memory is not dependable.

Yet a catalogue and a threat model answer different questions. A catalogue asks whether an expected practice exists and operates. A threat model asks how a particular actor could produce a particular loss despite or around those practices. The first promotes coverage. The second tests causation and composition.

Consider multifactor authentication. Its presence can satisfy a strong access-control expectation. A model must still ask whether enrollment can be socially engineered, whether recovery bypasses the second factor, whether corporate contacts are current, whether service accounts are exempt, whether session tokens can be stolen, whether help-desk staff can reset access and whether privileged actions require a second person. The weakness may be outside the login screen.

The same is true of backups. A backup control can operate on schedule while restoration credentials share the compromised identity domain, immutable copies are too old, data integrity cannot be established or recovery capacity is limited public evidence for the critical service. Monitoring can cover all servers while missing changes made through a trusted application. A vendor can hold a current certificate and still create concentration risk. A penetration test can find software flaws without testing whether a forged merger document transfers account authority.

NIST's Cybersecurity Framework 2.0 is explicit that organizations should govern, identify, protect, detect, respond and recover, and that priorities should reflect mission and risk. It is a useful common language, not a universal answer. The registry still has to define its own undesirable outcomes and choose an attack-informed profile. Buying every recognizable control is neither possible nor responsible.

Criticality is the consequence half of the model

RIPE NCC has published a Service Criticality Rating covering eight services across confidentiality, integrity and availability. It rates RPKI integrity and availability as very high. It gives the RIPE Database very high integrity, high confidentiality and high availability. RIPE NCC Access receives very high ratings for confidentiality and integrity, while the LIR Portal receives very high confidentiality and integrity with medium availability. K-root and authoritative DNS carry high integrity and availability ratings.

This is a strong piece of public reasoning. It recognizes that services fail in different ways and that integrity can matter more than continuous access. It also records that community assessment can be increased, though not decreased, by internal consideration of legal, financial or other risks. The table gives security teams a basis for service objectives, control selection, monitoring and cloud decisions.

Criticality, however, starts at the damage end. It says that a loss of RPKI integrity would be grave. It does not say which sequence is plausible: compromise of a member account, abuse of an internal role, a flaw in signing logic, dependency failure, incorrect recovery, coerced action, supplier compromise or an erroneous but authorized revocation. Each path calls for different prevention and recovery measures.

Nor does one rating reveal distribution. A one-hour outage affecting every relying party differs from a silent integrity error affecting one resource holder. A public website alteration differs from a change to authoritative registration data. A confidentiality event involving employee records differs from disclosure of member identity evidence. The model should pair each critical service with a small set of bounded loss scenarios and state which controls interrupt each sequence.

The criticality table can therefore become the front page of a mature threat model. It should not be treated as the final page. Boards need the bridge from critical consequence to adversary, dependency, path, preventive control, detection, recovery and residual exposure.

The threat set extends beyond cybercrime

Ransomware and financially motivated intrusion deserve attention. An RIR holds useful credentials, personal information and payment data, and an outage can create pressure to restore quickly. But a registry threat model that stops at generic cybercrime will miss actors interested in authority rather than ransom.

A resource hijacker may want a credible change to registration or authorization data. A sanctions evader may seek to obscure control of an organization or resource. A fraudulent buyer may present false acquisition documents. A state actor may value access to member records, strategic visibility or an ability to disrupt trust services. A commercial intelligence collector may seek non-public contact and organizational data. A disgruntled insider may possess legitimate access and knowledge of review thresholds. An ideological actor may seek embarrassment or service interruption.

A supplier compromise may give an unrelated attacker a route into the registry.

There are also non-malicious threat sources. Staff can make an incorrect high-impact change. A policy can have an unexpected technical consequence. A cloud provider can fail. An automated control can act on stale data. A court order or regulatory interpretation can force action under severe time pressure. A natural disaster, power event or telecommunications failure can coincide with a regional incident. A recovery attempt can damage integrity more than the original fault.

The governance value of naming actor classes is not theatrical speculation. Motive and capability determine where to spend. A ransomware defence emphasizes endpoint containment, identity, backups and recovery. Defence against a resource-control fraud requires corporate identity verification, transaction holds, independent confirmation and reversible states. Defence against a capable state actor demands stronger separation, supplier scrutiny and assumptions that some perimeter controls will fail. Defence against error requires change design, dual control, simulation and rollback.

The Board should insist that the model includes actors inconvenient to management. That includes senior insiders, trusted contractors, privileged suppliers and legally authorized external demands. Inclusion does not allege misconduct. It prevents trust status from becoming an exemption from analysis.

Identity recovery is a constitutional security function

RIR security often appears as a technical discipline, but identity recovery decides who may exercise institutional rights. When a member loses access, changes ownership, replaces a corporate contact or disputes an account, staff must determine which human speaks for which legal entity. That decision can control resources, voting, billing, transfers and certification services.

The ordinary security instinct is to make recovery possible but difficult. The governance requirement is more demanding: recovery must be consistent, reviewable and resistant to both impostors and institutional error. A process based on documents, email domains, telephone calls or officer attestations can fail without any software vulnerability. Jurisdictions maintain corporate records differently. Groups restructure. Insolvencies create competing representatives. Some members operate in conflict or under sanctions. National Internet registries and sponsoring organizations add another layer of authority.

An independent model should trace at least four identity sequences. The first is theft of an existing user's credential. The second is fraudulent enrollment of a new authorized contact. The third is abuse of a recovery or corporate-change route. The fourth is an insider or contractor using valid privilege outside a legitimate instruction. Controls should include notification to independent contacts, cooling-off periods for high-impact changes, dual approval, evidence retention, jurisdiction-aware verification, anomaly detection and a rapid appeal route.

Metrics must not reduce this function to login statistics. A high multifactor-authentication rate says little about recovery exceptions. A low number of confirmed account takeovers can reflect strong controls, low detection or a narrow definition. The better evidence is scenario testing: can a red team with plausible corporate documents and compromised email obtain authority; can staff detect a conflict among representatives; can the institution reverse a fraudulent change without destroying the audit trail?

Calling identity recovery constitutional is not exaggeration. It determines who can exercise membership and registry powers. The threat model should treat it with the same seriousness as cryptographic key custody.

RPKI assurance must test authority as well as software

RPKI creates a particularly clear case for threat-led governance. The service binds resource-holder authority to cryptographically verifiable entities. Its security depends on software, keys, repositories, account identity, certificate policy, operational roles, publication and relying-party behaviour. Strong controls in one layer cannot compensate for an unexamined authority path in another.

An assurance report can test whether specified controls were suitably designed and operated over a period. That is valuable. It can demonstrate discipline more credibly than institutional assertion. But the scope and criteria matter. A report may assess the certification service while excluding member-side compromise, a third-party dependency, a policy decision, a legal instruction or a failure mode outside the stated system boundary.

The model should identify undesirable outcomes rather than begin with control names. These include unauthorized issuance, incorrect revocation, failure to publish valid material, publication of inconsistent states, loss or misuse of signing capability, delayed recovery, account takeover leading to valid but hostile changes, and operator confusion during an incident. It should then show which controls prevent, detect and repair each outcome.

Independence is most useful at the boundary. Engineers who built the service understand implementation. Operations staff know failure behaviour. Legal staff understand terms and authority. Member operators know how validation affects routes. An independent challenger should test the assumptions connecting these domains: whether an action that is contractually authorized can still be operationally dangerous; whether recovery timing fits routing reality; whether relying parties can distinguish a registry error from holder action; and whether communication remains available when the primary service is impaired.

Public disclosure should remain high level. No member needs key locations, emergency credentials or exploitable dependencies. Members do need to know the scenario classes tested, the assurance boundary, material exclusions, recovery objective ranges and who accepted residual risk. An assurance badge without those boundaries can create more confidence than the evidence supports.

Suppliers can become the unmodelled control plane

The modern registry depends on cloud platforms, telecommunications, identity services, managed detection, software libraries, professional advisers, data-centre operators and specialist contractors. Each can improve security. Each can also concentrate access, knowledge or recovery power outside the institution.

NIST CSF 2.0 treats supply-chain risk as part of governance. Its outcomes call for requirements in contracts, due diligence before relationships, assessment throughout the relationship and inclusion of relevant suppliers in incident response and recovery. The logic is straightforward: the registry cannot claim to manage a service risk while treating the supplier operating a critical component as a purchasing detail.

A threat model should record not merely the vendor but the dependency. Can the registry operate if the vendor account is suspended? Can it export data and configuration? Who controls encryption keys? Can the supplier push changes without registry approval? Which subcontractors can access information? Is monitoring independent of the environment it observes? Does the institution possess the skills to challenge an alert or restore the service? How long would replacement take?

Managed security creates a special circularity. The same vendor may help define the risk, recommend the product, implement it, monitor it and report that it operates. None of those roles is improper by itself. Together they weaken independent evidence. At least one assurance route should sit outside the commercial chain being assessed. The Board's challenger should be able to inspect scope, test omitted scenarios and report without management or vendor editing the conclusion.

Exit is a security control. A supplier relationship that cannot be ended without intolerable service or knowledge loss creates leverage and a single point of institutional dependence. Contracts should provide access to logs, portable configuration, incident cooperation, subcontractor visibility, deletion evidence, tested transition and continuity during dispute. The model should put these obligations next to technical controls, not in a separate procurement appendix that directors never connect to cyber risk.

Security metrics can reward the wrong programme

Security programmes need measures, but easily counted activity can displace meaningful evidence. Numbers of vulnerabilities closed, staff trained, alerts handled, devices covered and policies approved are useful operating indicators. They become dangerous when presented as proof that institutional risk fell.

A team can close many low-risk findings while one authority flaw remains. Training completion can reach 100 percent while recovery staff have never rehearsed a contested corporate identity. Monitoring coverage can expand while supplier logs remain unavailable. Mean time to remediate can improve because difficult architectural weaknesses are reclassified or accepted. A clean audit can reflect a narrow scope. A year without a reported major incident can coexist with undetected compromise.

Threat-led metrics start from scenarios. For each severe outcome, the Board should ask whether a preventive barrier was tested, whether an independent signal detects failure, whether action can be contained and whether restoration preserves integrity. It should know how many critical paths depend on one identity provider, one supplier, one administrator class or one communication channel. It should see overdue high-risk exceptions and the age of accepted residual risks.

Exercise evidence is particularly valuable. How long did it take to establish trusted authority after a simulated account-control dispute? Could RPKI publication be recovered from a compromised administrative domain? Could member communications continue if the main website and email were unavailable? Could staff identify unauthorized but technically valid changes? Did the exercise reveal a policy, contract or staffing dependency that tools could not solve?

The point is not to reduce uncertainty to a dashboard. Some of the gravest risks resist frequency data. The Board should receive narrative judgment alongside measures: what changed in the threat environment, which assumption failed, what was learned, which investment moved as a result and what remains untested.

Independent challenge is a reporting relationship, not a consultant label

An external firm is not automatically independent. It may sell the recommended control, depend on management for renewal, have designed the system, rely on the same evidence or define success around its own service. Conversely, an internal security leader can produce rigorous analysis while a Board committee creates effective challenge. Independence arises from authority, incentives, access and reporting.

Management should own the operational threat model. Engineers, registry staff, legal advisers, member-services personnel and communications teams hold essential knowledge. Removing them in favour of a detached annual review would produce a polished but shallow document. The model must change with systems, suppliers, policy, law and incidents.

The independent layer should answer to the Board or a Board committee. It should have access to architecture, risk acceptance, incidents, test results, contracts and relevant staff. It should be free to select samples and scenarios. It should disclose commercial conflicts and should not earn implementation work automatically from findings. Its report should distinguish management fact, expert judgment, missing evidence and disagreement.

ARIN's published Risk and Cybersecurity Committee charter offers one governance reference. The committee oversees organizational and cyber risk, reviews the risk register, receives an annual cybersecurity risk assessment and can consider controls, compliance, technical debt and insurance. Earlier versions expressly noted the ability to obtain outside independent opinions. The charter does not prove the content or independence of any particular model; it shows how Board-level authority can be assigned.

For RIPE NCC, an equivalent public statement could identify which Executive Board body owns threat-model challenge, how often it reviews the model, when independent expertise is used and how material risk acceptance reaches the full Board. The institution need not reveal the protected report. It should reveal the accountability route.

The Board must decide what can be lost

Technical teams can estimate exploitability and design controls. They cannot legitimately decide alone how much member money to spend, which service degradation is tolerable, whether a legal or supplier concentration is acceptable or which residual risk belongs to the institution. Those are governance decisions informed by technical evidence.

The Board should begin with loss statements. It might determine that unauthorized alteration of resource-holder authority is intolerable; that a defined period of portal unavailability can be accepted if authoritative data remains sound; that no single employee or supplier may execute and conceal a critical change; that recovery from loss of the primary cloud identity domain must be demonstrated; or that a particular legacy dependency will remain for two years with compensating controls.

Such statements force trade-offs into view. If integrity is paramount, spending may shift from broad monitoring to transaction verification and recovery design. If a service can tolerate six hours of interruption, an expensive promise of near-zero downtime may be less valuable than reducing a silent-change risk. If a supplier exit would take a year, another product cannot disguise the concentration. If the Board accepts a risk because mitigation costs are disproportionate, members can at least see the category and accountable decision.

Directors need enough technical literacy to challenge without pretending to operate the systems. They should ask what evidence supports likelihood, which scenarios were excluded, whether the same party designed and tested the control, how the institution would know the control failed, what loss persists after mitigation and what cheaper or non-technical alternative was considered. They should request dissent, not only consensus.

The final decision should be recorded. A security budget approved without a risk-acceptance record leaves management to infer appetite from spending. That reverses accountability. The Board should set appetite and accept residual exposure; management should implement within it.

Public accountability does not require an attacker's handbook

Security secrecy is sometimes legitimate. Detailed architecture, vulnerabilities, privileged roles, recovery material, supplier weaknesses and exercise injects can enable attack. A governance demand that ignored those risks would be irresponsible. The choice, however, is not between full publication and silence.

A safe public abstract can state the institution's critical powers and service categories; the broad adversary classes considered; the dimensions of harm; major concentration and dependency themes; the risk-rating method; the Board's appetite; the categories of control funded; the independent challenge arrangement; the date of review; the owner of residual risk; and whether recovery exercises met their objectives. It can disclose that a material weakness is under treatment without locating it.

More detail can be shared with elected directors under confidentiality. A further annex can be limited to a small security committee and independent assessor. Exploitable evidence can remain with authorized operational staff. This tiered access gives the Board enough information to decide and members enough information to hold it accountable.

After an incident, disclosure should expand as the danger recedes. RIPE NCC's Responsible Disclosure Policy says major security issues may receive a report explaining the vulnerability and repair on a case-by-case basis. A mature incident account should also explain which threat-model assumption failed, whether the scenario had been considered, which control or dependency behaved unexpectedly and how budget priorities changed.

Aggregate disclosure helps comparison over time. Members should see whether the number of intolerable scenarios lacking tested recovery is falling; whether critical supplier exits are tested; whether high-risk exceptions age beyond deadlines; and whether independent review found repeated omissions. None of this requires naming a vulnerable host.

A minimum independent threat-model record

The first element is scope. The record should enumerate registry powers, critical services, sensitive data, authoritative publications, membership identity, internal administration and external dependencies. It should explain exclusions and identify who approved them. A model limited to the corporate network should not be presented as covering registry authority.

The second is actor and path analysis. It should include financially motivated criminals, resource-control fraud, capable state actors, insiders, contractors, compromised suppliers, erroneous staff action and coercive legal or regulatory events. For each high-impact outcome, it should identify preconditions, trust boundaries, likely sequences and controls that interrupt them.

The third is consequence and appetite. The institution should assess confidentiality, integrity, availability, operator harm, member harm, legal exposure, reputational damage and regional dependency. It should say which outcomes are intolerable, which are reduced and which are accepted for a period.

The fourth is evidence. The model should draw on incidents, near misses, vulnerability reports, architecture reviews, access data, exercises, member disputes, supplier tests and threat intelligence. It should label conjecture. A severe scenario can deserve treatment despite sparse frequency data, but the judgment should be visible.

The fifth is control and recovery mapping. Every funded control should connect to one or more scenarios. Every severe scenario should have prevention, detection, containment and integrity-preserving recovery, or an explicit residual-risk decision. Controls should include contracts, staffing, dual authority, legal verification and communications, not just software.

The sixth is independent challenge. The record should identify the challenger, appointment authority, conflicts, access, method, material disagreements and management response. The Board should record acceptance, required changes and review date.

This is not an argument for one enormous annual document. A concise model, maintained as decisions change, is more useful than a ceremonial report. The governance record can be assembled from living technical material while preserving one stable chain from threat to budget.

Spend should follow the model, and the model should survive the spend

The immediate budget test is simple. For every material cyber line, members and directors should be able to ask: which high-impact scenario does this reduce; how; by how much or to what target state; what dependency does it create; who will test it; and what would cause renewal, redesign or termination? A line that cannot answer may still be necessary, but it has not yet earned priority.

The reverse test is more revealing. For every intolerable or high residual scenario, the Board should see whether a funded response exists. If not, it should know whether the gap reflects technical infeasibility, proportionality, timing or oversight. This catches the quiet risk that does not correspond to a product category.

Procurement should preserve the model's independence. A supplier must not write requirements that only its product satisfies, define the risk reduction, implement the solution and provide the sole success evidence. Contracts should require measurable outcomes, data access, incident support, portability and exit. Independent testing should report to the institution, not through the vendor whose work it evaluates.

Budget phasing should also follow uncertainty. A registry does not have to commit a full multi-year programme to learn whether a suspected path is material. It can fund a bounded architecture review, an adversarial exercise or a recovery test before buying the permanent control. It can require a pilot to produce evidence about false positives, staff burden, supplier access and actual decision speed. The next tranche should depend on that evidence. This turns uncertainty into an explicit investment stage rather than a reason to accept a vendor's most comprehensive package.

Opportunity cost belongs in the security decision. A million euros spent on a new monitoring layer cannot also fund replacement of fragile software, additional separation of duties, a second recovery team or member identity verification. Directors should receive at least one credible alternative for every major proposal, including a process change and a decision not to proceed. The comparison should use the same loss scenarios. It is not enough to compare product features while leaving the institutional objective unpriced.

Recurring cost needs a baseline as disciplined as the purchase case. Licence growth can follow employee count, log volume, data retention or number of protected endpoints even when risk is unchanged. Consultancy can persist because implementation knowledge never transfers. Audit scope can expand because one assurance requirement is used to justify another. The Board should see the five-year cost, internal staff requirement, exit cost and new dependency created by each programme. A control that consumes scarce engineers may weaken another defence despite appearing affordable in the procurement total.

The distribution of benefit matters as well. Members pay collectively, but failures do not fall evenly. A large operator may maintain independent monitoring and experienced security staff; a small member may rely heavily on registry notices and account recovery. A resource holder in a jurisdiction with weak corporate records may face greater friction from identity controls. Security design should examine who bears false positives, delayed transfers, account locks and documentation demands. Reducing one threat by making legitimate control impracticable for part of the membership is not costless risk reduction.

The institution should preserve a decision ledger from scenario to expenditure. It need not disclose sensitive amounts by supplier, but internally it should show the original risk statement, options, approval, expected result, implementation evidence, exceptions, incidents, renewal decisions and retirement. The independent challenger can then test whether the justification moved after purchase. Without this history, every renewal begins from the claim that the control is now essential, even when no one can reconstruct why it was chosen.

Member scrutiny can improve this discipline if the question is framed correctly. A public consultation should not ask non-specialists to approve a product architecture. It should ask whether the loss priorities reflect operator dependency, whether important constituencies or scenarios are missing, whether proposed transparency is sufficient and whether the Board has explained residual risk. Operators can contribute observations about routing consequences, recovery timing and communication failure that an internal corporate assessment may miss.

Finally, the model must survive sunk cost. Once an institution has invested in a platform or certification, there is pressure to treat continuation as proof of seriousness. Threats and architecture change. A model may show that a control is redundant, a supplier has become the greater risk or a non-technical change would reduce more harm. Ending a security product can be a mature decision if evidence supports it.

RIPE NCC's detailed plans, service-criticality table and assurance commitments provide much of the raw governance material. ARIN's Board committee structure demonstrates an explicit oversight route. APNIC's public security description draws a useful boundary between registry duties and functions that belong to operators, incident responders or law enforcement. The next step is to connect such material into an independently challenged allocation argument.

Security spending is easiest to approve when fear is general and responsibility is diffuse. A registry entrusted with durable public authority should demand the opposite: bounded scenarios, named owners, protected evidence, independent challenge and a Board decision. The threat model does not replace controls. It makes the institution explain why these controls, in this order, against these losses, are worth the members' money.

Sources