Summary

  • RIPE NCC’s Q3 2026 security plan contains four different work lines, all labelled “In progress”: assurance and standards, organisational risk and GRC, application security and penetration testing, and monitoring plus managed services.
  • Those lines do not produce interchangeable evidence. An audit report, a risk-treatment decision, a remediated vulnerability and a monitoring alert each answer a different question.
  • RIPE NCC should publish a compact, non-sensitive handoff map: scope, evidence class, accountable function, acceptance event, downstream dependency, retest date and public claim—while keeping vulnerabilities, control detail and audit workpapers private.

“In progress” is one of the most respectable phrases in institutional reporting. It refuses to turn unfinished work into a victory lap. It also carries almost no information about what must happen next.

That limitation matters on RIPE NCC’s Information Security, Risk and Compliance planning page. The Q3 2026 edition, last updated on 11 June, presents four items. The first covers external work for the annual SOC 2 Type II assurance report for RPKI and the continuing path towards ISO 27001 certification. The second combines an annual risk assessment with onboarding a Governance, Risk & Compliance platform. The third joins application-security capabilities to the foundations of a penetration-testing programme. The fourth pairs wider security-monitoring coverage with the acquisition of managed security services.

Every item has the same status: “In progress”.

The page is doing what it says on the tin. RIPE NCC describes it as a transparency and consultation surface: a place to show planned work, invite suggestions, document consequential feedback and maintain a dialogue with members and the community. It is not an audit report, a risk register or a service-level dashboard. Demanding that it become all three would be poor security practice and worse governance.

Yet the four-line presentation creates a second problem. It makes distinct kinds of evidence look parallel when, operationally, they are dependent. A finding from an internal audit may become a risk treatment. A risk treatment may require an application control. A penetration test may challenge that control. Monitoring may show whether the repaired system behaves as expected. An external auditor may then test only a defined service, period and control framework. None of those acts can substitute for the others.

But without a map of the handoffs, the public reader cannot tell whether the four lines are a chain, four independent projects, or some mixture of both.

The missing object is not another score. It is a record of passage.

Four rows, four different claims

The standards row is the easiest one to overread. RIPE NCC’s 2025 Annual Report says the organisation received a SOC 2 Type II assurance report for RPKI in December 2025, following a Type I report in 2024. The approved 2026 Activity Plan says the Type II exercise will be annual and schedules another cycle. The current quarterly plan says external audit activities will run in Q3 and Q4. These statements fit together. They describe a completed report for one period and work towards a later report for another.

They do not create a permanent badge. A Type II report concerns controls within a defined scope and review period. The fact that a prior cycle concluded does not prove that a later cycle has concluded; the fact that a later cycle is under way does not make the prior report worthless. The relevant handoff is temporal: which previous observations or improvements enter the new audit, which evidence period is being tested, who accepts exceptions, and when the next public claim becomes supportable.

ISO 27001 is another claim with a different finish line. The Q3 page says RIPE NCC is addressing recommendations from an internal audit and planning the certification audit. The Activity Plan speaks of achieving certification. Those are not synonyms for being certified. Internal recommendations, management-system readiness and an external certification decision are successive evidence states. A public map need not reveal a single recommendation.

It can say whether the recommendation phase has closed, whether the certification audit has been scheduled or completed, which services sit inside the stated scope, and what event authorises a change in the public status.

The risk-and-GRC row produces something else again. An annual risk assessment identifies and evaluates risks within an organisational method. A GRC platform can improve custody, versioning, assignment, reminders and reporting. It cannot decide how much risk an institution should accept. That authority belongs to people operating under an approved governance arrangement.

RIPE NCC’s published Board minutes make that human layer visible without exposing the risk register. At meeting 189, management reported that 80% of risk-treatment plans were executed on time and that no material security incidents had been reported. The Board approved revised risk-appetite statements. At meeting 194 in June 2026, the Board received a status report on high risks and treatment plans and an update on rolling out the revised appetite. The minutes do not publish the risks or the treatments. Nor should a serious observer infer that the missing detail does not exist.

What the record does show is a route from assessment to treatment to a level of acceptance that, for the highest residual risks, reaches the Board.

The GRC system sits inside that route. The interesting question is not whether onboarding has reached an arbitrary percentage. It is whether a risk accepted, treated or escalated in the system can be linked to the evidence produced elsewhere: an audit observation, an application-security exception, a penetration-test result, an incident exercise, or a monitoring gap. A platform with immaculate fields but weak handoffs merely makes fragmentation easier to search.

The application-security row turns from institutional risk to the development lifecycle. The quarterly plan says the aim is to identify and remediate vulnerabilities proactively and to lay the foundation for an organisational penetration-testing programme. The verbs matter. Finding, triaging, fixing and verifying are different actions. A scanner can produce a finding; it cannot establish the business context. A development team can ship a repair; it cannot by that act prove the repair resists an independent test. A penetration tester can demonstrate a weakness; the test does not itself assign the risk owner or operate a compensating control.

Here the crucial handoff is a closed loop. A finding needs a service owner, severity basis and treatment decision. A repair needs a version and deployment boundary. Verification needs an independent result. Any residual risk needs an accountable acceptance and an expiry or retest date. The public does not need exploit steps, affected endpoints or an inventory of open defects. Members can still be told whether the loop exists, what class of evidence closes it, and whether closure feeds the organisation’s risk view.

The monitoring row looks closest to operations, but it also contains two non-equivalent ideas. Expanding monitoring coverage is a claim about what can be observed. Acquiring managed security services is a sourcing decision about who may help observe or respond. Neither proves that an incident was prevented, detected in time or resolved well. The official emergency page says RIPE NCC monitors critical services around the clock, naming the RIPE Database, K-root, DNS and reverse DNS, the LIR Portal, RPKI and its websites. It also says confirmed incidents are placed on the Service Announcement page.

That is a useful public boundary. It identifies monitored service families and an incident-communication surface. It does not specify every telemetry source, detection rule or supplier duty. A handoff map could preserve that boundary while answering safer questions: Does monitoring coverage feed the risk assessment? Who owns the decision that a signal becomes a confirmed incident? When an incident reveals a development weakness, does it create a tracked application-security action? When a supplier sees the signal first, which RIPE NCC function accepts the alert and owns closure?

The public evidence surface is already plural

RIPE NCC does not publish security information in one place. Its quarterly plan describes activity and invites input. The Activity Plan describes commitments, staffing and intended costs. Board minutes record governance decisions and management reports at a high level. The Trust Portal is meant to present security, compliance and assurance information. The status page carries confirmed operational incidents. The responsible-disclosure policy governs vulnerability intake and promises an evaluation and expected resolution date within three business days; it says a report after a major issue may be published case by case.

For RPKI, the Certification Service terms say information about security policies and measures will appear in the Trust Portal, while available audit reports may be shared with certificate holders on request under a non-disclosure agreement.

These are not duplicate channels. They serve different readers and protect different things. A vulnerability reporter needs confidentiality and a rapid acknowledgement. An operator facing an outage needs a current service notice. A member assessing institutional assurance needs scope, period and the basis of a claim. A Board overseeing residual risk needs access to information that would be reckless to publish.

The governance task is therefore not radical transparency. It is coherent transparency. Each public claim should tell the reader what evidence surface supports it and where the next handoff occurs. “RPKI Type II report received in December 2025” can link conceptually to the annual assurance cycle. “ISO work in progress” can distinguish recommendation closure from certification. “Monitoring expanded” can state the service boundary and acceptance date without naming rules. “GRC onboarded” can say which classes of risk and evidence have entered the system without exposing the register.

The distinction is more important because the 2026 Activity Plan distributes compliance work beyond the Information Security, Risk and Compliance line. It assigns security and standards work to RPKI, the RIPE Database, DNS and K-root, the LIR Portal and IT Support. The security function may set methods and consolidate evidence, while service teams implement controls and own operational facts. A single departmental status can therefore conceal a healthy dependency: one programme cannot close until another team has supplied evidence. It can also conceal an unhealthy one.

The public does not need to know which is which at the vulnerability level. It does need to know what “done” means at each boundary.

What a handoff map would contain

The map can be small. One row for each bounded assurance claim would be enough.

First, name the programme and the claim it can support. “Annual RPKI Type II assurance for the stated period” is better than “compliance”. “ISO 27001 certification decision for the declared scope” is better than “security maturity”. “Development findings closed under the application-security process” is better than “secure applications”. Precision reduces the temptation to make a narrow result carry a broad promise.

Second, name the service or organisational scope. RPKI assurance is not automatically assurance for every RIPE NCC system. An organisation-wide management standard can still have a declared certification boundary. Monitoring can cover a named critical-service set without covering every internal asset. Scope is not an embarrassment; it is the condition that makes a claim testable.

Third, identify the accountable function, not an individual analyst. The service owner, Information Security function, Risk and Compliance function, executive team or Board can be named according to the decision. The point is to keep automation from becoming the apparent owner. A ticket may be updated automatically; risk acceptance cannot be.

Fourth, state the input evidence class and its as-of date. The entry need not reveal a finding. It can say “internal-audit recommendations”, “external assurance evidence”, “penetration-test closure evidence”, “monitoring coverage review” or “Board-approved risk appetite”. Dates prevent one cycle’s evidence from drifting into another cycle’s claim.

Fifth, record the handoff and acceptance event. A recommendation may pass to a service team for remediation. Closure evidence may pass to the security function for verification. A residual risk may pass to management or the Board for acceptance. A control result may pass to an auditor. “Accepted” should say by which function and under what kind of authority, not merely that a workflow state changed.

Sixth, give the downstream dependency and retest date. The map should show, for example, that certification readiness depends on recommendation closure, or that risk treatment depends on verified application work. It should also show when a claim must be renewed. Security evidence ages. The honest expiry is often more informative than a permanent green icon.

Finally, point to the public surface carrying the resulting claim: quarterly plan, annual report, Trust Portal, service status or Board minutes. The map would not replace those surfaces. It would stop them from becoming isolated islands of technically true but institutionally ambiguous text.

The strongest objection is also the design constraint

RIPE NCC has good reasons not to publish its control inventory or dependency graph. Attackers benefit from implementation detail. Audit workpapers can contain sensitive tests. Risk registers can identify fragile processes and named owners. Managed-service contracts can expose escalation paths. Early findings change, and a public progress table can turn professional remediation into theatre.

That objection defeats a maximal map. It does not defeat a bounded one.

A safe public row can omit the vulnerability, tool, supplier, system component and finding. It can say that an evidence class was received, which function accepted it, what bounded claim it supports, what other programme depends on it and when it will be revisited. This is much closer to a train connection board than a network diagram: it shows that a transfer exists and whether it has occurred, not the machinery underneath the platform.

Another objection is that the four “In progress” labels are already proportionate. The page is a quarterly invitation to comment, not a securities filing. That is correct. The proposed map should not turn it into a compliance prospectus. It can live on the Trust Portal or beside an annual report, with the quarterly page linking to it. A reader who only wants the plan can keep the short view. A member deciding how much assurance to attach to the words can inspect the connections.

A third objection is that RIPE NCC may already operate exactly this discipline internally. The GRC onboarding, Board reporting, audit work and service management could be joined by mature processes that the public sources do not expose. That possibility should be stated, not waved away. The case for a public map is not that the internal system is absent. It is that a membership organisation makes several public claims whose relationships cannot currently be reconstructed from the public packet without inference.

A status that can close

“In progress” is useful at the beginning of a quarter. It becomes less useful at the next decision point unless it has a closure rule. Each of the four lines needs a different one.

For the RPKI assurance cycle, closure is not “the auditors were active”; it is the dated issue or formal disposition of the report for the stated period. For ISO 27001, it is not “recommendations were addressed”; it is the certification body’s decision for a declared scope, or an accurate statement that the decision remains pending. For GRC onboarding, it is not “the platform is live”; it is that agreed risk, control, treatment and evidence classes have accountable owners and migration acceptance. For application security, it is not “a scanner runs”; it is that finding-to-fix-to-verification routes operate under defined exception authority.

For monitoring and managed services, it is not “more telemetry was purchased”; it is that coverage and escalation have been accepted for a named service boundary and tested.

Those closure rules would also improve community input. Members could ask about the relationship that matters rather than requesting sensitive detail. Did the internal-audit recommendation phase feed certification readiness? Does a penetration-test exception enter the annual risk assessment? Does managed detection have a RIPE NCC acceptance owner? Which public claim will be updated when the next annual RPKI report is issued?

Questions like these are more demanding than a progress percentage and safer than a control dump. They turn transparency into an interface between institutions and operators.

RIPE NCC’s four lines are not evidence of failure. They are evidence that security work is distributed across assurance, governance, engineering and operations. The public record already shows serious components: recurring external assurance, a certification programme, Board-approved risk appetite, treatment reporting, responsible disclosure, round-the-clock monitoring and a Trust Portal. The missing piece is the connective tissue.

Give each programme its own bounded claim. Show the handoff. Name the accepting function. Date the evidence. Set the retest. Then “In progress” can remain modest without remaining opaque.

Sources