Operated service
OffRecord by Somos-Co
Have applications operated against a defined security baseline and a documented operating model.
- Role
- Own managed service
- Status
- Active commercial offering
- Classification
- Operated service
Architecture
Sequence
- Delivery
- Application online
- Request
- Operations
Development environment · Delivery 1/3The starting point of a change: development and local verification before it enters the defined delivery process.
CI/CD · Delivery 2/3Changes run through the defined pipeline — build, test and version — before reaching the target environment.
Deployment · Delivery 3/3The controlled step into the environment: defined deployment processes rather than manual intervention.
Internet · Request 1/3The public entry point. Everything behind it runs over a controlled traffic path.
Edge / origin shield · Request 2/3Edge and origin-shield layer in front of the cluster — the request path does not start at the application.
Ingress · TLS · Request 3/3Ingress with TLS termination and routing forms the controlled path to the application.
K3s cluster · System boundaryThe Kubernetes or K3s environment, bounded by RBAC and network policies.
Namespace · System boundaryThe bounded area inside the cluster where the application runs. Network policies, RBAC and network segmentation apply at this boundary.
Application · Where both paths endThe operated application, containerised in its own namespace. Both paths — request and delivery — end here.
Monitoring · Operations channelMonitoring and alerting make system state visible; incident workflows are documented.
Backup / restore · Operations channelBackup and restore as a documented part of the operating model.
The sequence begins in the development environment. From there, a change runs through CI/CD and a controlled deployment step into the application, which is then online. The request path subsequently runs from the internet through an edge and origin-shield layer to ingress with TLS termination and from there to the application. In operations, monitoring and alerting expose system state; backup and restore are part of the operating model. The cluster is bounded by RBAC and network policies.
Context
OffRecord by Somos-Co is a managed platform service for applications that have to run reliably but do not justify a dedicated operations team. The service covers the Kubernetes / K3s environment, the operation of the applications on it, and the associated operating processes.
Business problem
Many organisations can build an application, or have one built, but have no dependable operation for it: updates are applied by hand, nobody can see the system state, backups exist but have never been restored, and when something breaks it is unclear who decides. The problem is rarely the technology — it is the absence of operating accountability.
Mandate and role
What Somos-Co owns
OffRecord is a Somos-Co offering. Somos-Co takes technical operating responsibility within the agreed scope.
What the partner or customer owns
Functional responsibility for the operated application remains with the customer.
Outside the role
Full penetration testing, red teaming and formal regulatory security audits are not part of the service; the agreed scope in each case follows from the contract.
Intervention
- 1
Provision of a managed Kubernetes / K3s environment
- 2
Definition and implementation of a security baseline
- 3
A controlled traffic path including an origin shield
- 4
Monitoring and alerting
- 5
Backups, including verified restore
- 6
Documentation of the operating processes
Technical scope
Platform
- Managed Kubernetes/K3s
- Routing, ingress, TLS and origin shield
Operations
- Security baseline, hardening, network policies, RBAC and secrets management
- Monitoring, alerting and logging
- Backup and restore
- Controlled deployment and operating processes
Operating model
Operations follow documented processes: changes run through defined deployment paths, system state is visible through monitoring, backups are taken regularly and restores are verified. Responsibilities between Somos-Co and the customer are delimited in writing.
Current status
OffRecord is an active commercial offering with initial commercially remunerated customers and platform partnerships.
Result and evidence
- Operated environments have a defined security baseline rather than accreted one-off configuration.
- System state is visible through monitoring.
- Backups are in place and restore is verified.
- Operating responsibility and escalation paths are documented.
Limitations of these statements
- A security baseline reduces risk; absolute security is not claimed and cannot be promised.
- No availability or SLA figures are published on this page; the agreed scope follows from the contract.
- The service does not include full penetration testing, red teaming or formal regulatory security audits.
- Functional responsibility for the operated application remains with the customer.
Next stage
Extension of operational automation and observability in line with the actual needs of the operated applications.
Problem Check
Which business decision needs a more reliable basis?
Describe the challenge, affected process and timeframe. In an initial Problem Check, we clarify which questions a dynamic model should answer.
For applications, platforms, IoT and digital-twin work, and managed operations.