# Answering a platform security control catalog

Security requirements arrive as a numbered list. Someone has to say, per line, whether the platform does this, whether it is included, and what evidence comes with it. That answer usually gets rebuilt from scratch for every bid, which is slow for us and slower for the buyer waiting on it.

So here it is once, for a VSHN-operated OpenShift platform. Each control says which of three things it is: **included** in the managed platform, an **add-on** that is ordered and priced separately, or **yours**. A page that blurred those three would be useless for the purpose you are reading it for.

The last section names the controls this page does not answer yet, rather than letting silence imply a no.

## Network segmentation

**Included.** Managed OpenShift uses Cilium as its default container network interface, so network policy enforcement is part of the platform rather than something added later. Namespaces, RBAC and Security Context Constraints come from OpenShift itself.

**Add-on: [Isovalent Enterprise Platform](https://products.vshn.ch/openshift/cilium.html).** Where a requirement asks for more than policy at the network layer, this adds identity-based micro-segmentation, policy enforcement across L3, L4 and L7, transparent IPsec or WireGuard encryption between nodes, and an egress gateway for workloads that must leave the cluster from a known address.

It is priced per feature and per node capacity, in two tiers, and the [current rates](https://products.vshn.ch/openshift/cilium.html) are published rather than quoted per deal. Read them there rather than here: they are reference rates that final billing adjusts against actual consumption, and a price copied onto a second page is a price that goes stale without anyone noticing. Features Isovalent marks as beta, and non-standard configuration, are not supported by VSHN unless that is agreed explicitly.

## Administrative access

**Included, and worth reading before you write the requirement.** VSHN operates the platform with automation, which means the systems have to be reachable at all times without a person in the loop. Manual access paths are excluded by design: personal VPN clients, remote-desktop jump hosts, hardware tokens handed to an engineer, and access that depends on someone's notebook.

That is not the same as refusing your access controls. VSHN can provide the SSH and VPN jump hosts itself, and in practice complies with most customer information security policies. VSHN employee and service accounts are managed exclusively through VSHN Configuration Management, so there is a single place where access is granted and withdrawn.

The distinction that matters for your catalog: a jumphost that automation can traverse unattended works, and a jumphost that requires a human approval step for every session does not. If your requirement is the second kind, say so early. It is an architecture question, not a configuration one, and it has derailed larger infrastructure projects than this one.

## Logging, SIEM export and forensics

**Included.** Cluster-internal logging, collected and available to debug service errors.

**Add-on, in the same Isovalent platform as above.** Hubble supplies identity-aware flow logs that record the policy verdict alongside the connection, so a log line says not just what happened but which policy allowed or denied it. Hubble Timescape keeps that history for exploration after the fact. **SIEM Export** ships those events into your own SIEM, as its own line item on top of the networking tier rather than as a standalone purchase. Tetragon adds runtime security, correlating process-level events with network events, which is what a forensic question usually needs.

This is the honest shape of the answer: a SIEM feed exists, it is a named product with a published rate, and it is ordered rather than assumed.

## Monitoring and incident handling

**Included, and the level is what you pick.** The service level profile decides it:

| | Baseline | 99.9% Business Hours | 99.9% 24/7 | 99.99% 24/7 |
|---|---|---|---|---|
| Availability target | No formal commitment | 99.9% | 99.9% | 99.99% |
| Measurement window | Not measured | Mon to Fri, 09:00 to 18:00 CET | 24/7 | 24/7 |
| Response target | Not included | 2 hours, business hours | 2 hours | 1 hour |
| Root cause analysis | Not included | On request | On request | Mandatory, within 5 days |
| Service credits | No | Yes | Yes | Yes |

VSHN monitors the platform and reacts on SLA-relevant alerts within the window you bought. Note that around-the-clock monitoring and incident handling is what the 24/7 profiles include; a named on-call engagement for your own application is a separate plan, and conflating the two is the most common mistake in reading a service level table.

Full profile detail, including how availability is measured and how credits are calculated: [VSHN service levels](https://products.vshn.ch/service_levels.html).

## Backups

**Included.** Backups run daily. The default retention keeps the last seven daily backups plus four weekly ones, and a different schedule, including multiple runs per day, is available as an option. Data is encrypted on the client before it leaves the machine and then transferred over a TLS connection to an off-site target in Swiss datacenters, selected by VSHN. Custom locations are available on request.

**The part worth asking every provider about:** backup success is itself monitored. Days without a successful backup is a tracked indicator with a threshold of one day on the higher service profiles and three on Baseline, which means a silently failing backup surfaces as an incident rather than as a discovery during a restore.

**Yours.** Your retention and classification policy, and the recovery point your business actually requires, which is an input to the design rather than an output of it.

## Operating system hardening

**Included.** The machines underneath the platform are hardened by configuration, not by a one-time checklist: SSHd configuration, IPtables as a local firewall, sudo restrictions, enforced package repositories, NTP and DNS resolvers, semi-automated weekly package updates, and 0-day mitigation outside that cycle when it is needed. Because it is configuration management rather than a build step, drift is corrected continuously and the state is reported rather than assumed.

## Four controls that are not cluster-level

The rest of a typical catalog asks for things a platform cannot answer on its own, because they are properties of your architecture rather than of a cluster. Naming which ones, and why, saves an argument later in the evaluation.

**Disaster recovery, and a stated RPO and RTO.** Whether you need cold, warm or hot standby follows from your overall architecture, not from the cluster underneath it. A published recovery point would therefore be wrong for most readers of this page, so the concept is designed per customer instead. What can be said before that design exists is what constrains it: a Swiss provider's own replication limits usually decide the answer, and georedundancy across two sites is built rather than ordered.

**Four-eyes and segregation of duties.** Enforced at the source level, through merge request approval, rather than on the platform. That is deliberate rather than a gap. Nothing on a VSHN-operated platform should be changed by hand, so a platform-side approval gate would guard a path nobody is supposed to use, while the change that actually reaches production passes beside it. The control belongs where the change is authored.

**Central log storage across clusters.** Also an architecture question rather than a cluster one. Where logs are aggregated, how long they are kept and under whose retention rules depends on what else you run, so it is designed with you rather than shipped as a default.

**Cloud security posture management, and integration with your own PKI or certificate authority.** Built per customer. Both are real and neither is part of the standard package, which is a distinction worth having in writing before a contract rather than after.

If your catalog includes any of these, [ask](#contact). The answer is an architecture conversation, and a short one.

Related: [what VSHN operates and what stays with you](https://www.appcat.ch/operating-model/), and [sovereignty](/sovereignty/) for jurisdiction, ownership and the CLOUD Act.