A provider manages your log collector over VPN. What may it do?

A worked scope class for one of the most common ways a provider reaches into a company: a VPN, then SSH to the servers it looks after.

The servers collect your logs, so what the provider does on them matters. This scope class sets what the provider may do there, and every session and every change is reported by both sides.

Everything on this page is illustrative. It is not published as a scope class, it binds nobody, and no member is admitted into it. The real one for your systems is written with you.

All example scope classes · Illustrative example · 25 September 2026 · Read with the rulebook

In one minute

Two parts, never mixed. Part A is the scope class itself: the guardrails. Part B is the evidence: how each side proves what happened. Part B is an example, not a rule.
The guardrails are short. Each action the provider can take is allowed or denied, and an allowed action may carry a limit.
Both sides report. The provider signs a statement for every session and every change. You report what you saw on your own servers. The two are matched.
Every breach is a yes-or-no question. No judgment and no argument about intent.
Rootwall confirms that no guardrail has been broken. The provider has signed for what it did, checks itself first, and owes a sum fixed in advance when a guardrail is broken or the two sides do not match.

The scenario

The company (the receiving member) runs a log collector. It receives the organization's logs, process them, and forward them to the company's security operations platform (its SIEM).
The provider (the emitting member) manages the collector remotely: a VPN, then SSH to the servers.
Why it matters. A change to the collector’s configuration decides which of your logs reach your SIEM, so every change should be one you approved.

The collector decides what reaches your SIEM, so changes to it are what this scope class governs most closely.

Part A

The scope class: the guardrails

Reference SC-ADMIN-1 (illustrative) · a session is one SSH session · an interaction is one administrative action

The guardrails

Each action is allowed or denied, and an allowed action may carry a limit. These are control points based on rules. They make sure the provider behaves, or it pays a fixed sum.

Action	Rule	Limit
Open a session to a declared server	Allow	Up to 10 a day
Read the application's status and its own logs	Allow	—
Restart the application	Allow	Up to 2 a day
Change the application's configurationThe action this scenario exists for	Allow	With an approved change
Update the application's software	Allow	With an approved change
Change access to the serversAccounts, sudo rights, SSH settings and trusted keys	Allow	With an approved change
Reach anything through the tunnel other than the declared serversAn attempt counts, whether or not it was blocked	Deny	—

“With an approved change” means a reference from your own change process, the one that already approves production changes, covering those servers, that time window and that kind of change. Emergency changes go through your emergency change process like any other.

What the reports cannot see stays with your own controls: settings in your cloud console, onward connections from the servers, data copied off. You may always be stricter.

In the rulebook's terms, the approved change is the Delegation: the authority an action rests on.

What each side reports

The provider reports	You report
At session open: engineer, server, purpose, session identifier	Each session seen on your servers
For each change, update or restart: the change reference and a fingerprint of the file before and after	Each change seen on your servers, with the same fingerprints
—	That the change reference exists, is approved, and covers those servers and that window
Each hour: tunnel up and down times, count of sessions	Each hour: the same counts, and any attempt through the tunnel to an address other than the declared servers, from your network flow logs

Both sides count the same way: same clock, same window edges, same definition of a session.

Session report: before the first action.
Change, update or restart report: within 5 minutes.
Hourly report: within 1 hour of the window closing.

What is a breach, and what it costs

#	Breach	Fixed sum
B1	Reaching anything through the tunnel other than the declared serversAn attempt counts, whether or not it was blocked	$250per session
B2	A change to a watched file with no approved change behind itThe breach this scenario exists for	$500per change
B3	A session or change you saw, with no report from the providerNever cheaper than B2: silence must not pay	$500per session
B4	The two sides do not match: fingerprints, times or counts differ	$250per session
B5	A late report, or a slip: the change reference left out or mistyped when an approved change did existThe common case: a provider that forgot	$50per report
B6	A limit exceededSessions or restarts above the daily limit	$100per day

Forgetting is cheap. An unapproved change is not.

Sums are paid by the provider to you, never to Rootwall. No single breach costs more than half of a provider’s yearly membership. Aggregate cap: $5,000 per provider, per counterparty, per rolling 30 days. Standing moves too: repeated breaches put a provider under review, and can suspend it. Illustrative figures for this example.

Part B

The evidence: one way to prove it

An example mapping. Each member maps its own systems (clause 13.2). Not a rule.

Which session an action belongs to

SSH certificates carrying the session identifier. Your servers trust the provider's certificate authority rather than individual keys. Before each session, the provider's jump host signs the session report, then issues a certificate valid for about an hour with the session identifier in the certificate's key ID field.

Your SSH server writes that key ID into its login record. Every login on your side points to exactly one signed report on the provider's side. A login with no identifier, an unknown one, or an expired one is a breach.

ssh-keygen -s provider_ca -I RW-PRV01-20260925-0001 \
  -n appadmin -V +1h -O source-address=10.9.0.5 engineer.pub

Accepted publickey for appadmin from 10.9.0.5 ... ED25519-CERT
  SHA256:... ID RW-PRV01-20260925-0001 (serial 42) CA ED25519 SHA256:...

The rest of the evidence

What must be shown	How, in this example
That a change happened, and what changed	Both sides fingerprint (hash) the watched files: the application's configuration and software, and the servers' access files
That a change was authorized	Your change-management record for the quoted reference
Tunnel and session counts	Provider: its VPN or firewall logs. You: your cloud network's flow logs, which also show any attempt to reach another address

Why the provider's report matters, when you could check alone

It is signed. "I did this, under this change reference." Without it the provider can say "not us", and the fixed sum becomes a dispute.
It puts the first check on the provider. The provider must stop its own bad conduct before you have to find it.
A mismatch is itself a breach. A provider cannot quietly report something different from what happened.

The defense is the product. The payment is the incentive.

Known limits

A report states what the provider declares, not every command typed, unless sessions are recorded. The fingerprints are what prove a change happened.

Getting used to it

Reporting every session and every change is a new routine, so the first 30 days are a warm-up. Everything is reported and matched, and both sides see the results every week. No fixed sums apply and nobody's standing changes. The warm-up ends on its own.

Proposed for the next version of the rulebook, where it would apply to every scope class. Not yet in force.