Security and resilience

Opsenium-managed systems are hosted on Microsoft Azure, in the UK South region by default. Each system has its own resource group, its own managed identities and its own key vault, so clients are separated at the platform level rather than by convention.

Access to systems is role-based and scoped, enforced in the application at every relevant call site. Staff and administrators sign in through the client’s identity provider, such as Microsoft Entra ID, where one exists. Multi-factor authentication and single sign-on can be required for administrative access. Service identities are granted only the permissions they need.

Data is encrypted in transit with TLS and at rest by the platform. Non-recoverable credentials issued by a system, such as passwords, PINs and device tokens, are stored using one-way hashing. Recoverable provider credentials and integration secrets are held in Azure Key Vault or encrypted at rest in the application with a versioned scheme, and are accessed through managed identities rather than shared keys.

Systems record an audit trail of significant actions with the actor, the time and, where relevant, the before-and-after state, including drafts produced with AI assistance alongside the versions a person approved. Application telemetry and logs are retained in Azure Monitor for an agreed period. Audit records are available to the client.

Availability tests, application telemetry and alert rules are configured for every managed system. Alerts route to Opsenium and, where the client wants them, to the client. Background jobs record their attempts so that failures are visible rather than silent.

Databases use the platform’s point-in-time restore. Managed systems additionally take scheduled, encrypted backups to an independent provider under an immutable retention lock, so that a compromised environment cannot delete its own recovery position. Backup integrity is checked when the backup is written.

Each managed system has documented recovery point and recovery time objectives, a runbook listing its resources including those managed by hand, and a documented rollback and recovery path appropriate to each application component and database change. Restores are rehearsed and the drill is dated and timed in the runbook.

Code is version controlled, reviewed and tested automatically before deployment. Deployment pipelines authenticate to Azure with short-lived federated credentials rather than stored secrets. Infrastructure is defined as code. Security headers, rate limiting and restricted origins are standard on every service.

Runtime and library dependencies are updated on a schedule under the managed service, and container images are rebuilt from current base images. Vulnerability advisories for the stack are monitored and urgent patches are applied outside the schedule.

Incidents are tracked from report to resolution under the service agreement, with severity-based response targets. Significant incidents receive a written account covering cause, impact, resolution and the change made to prevent recurrence. Personal data breaches are handled in line with UK GDPR obligations and the client’s own procedures.

Retention periods are agreed per system and per kind of data, and enforced by scheduled processes rather than by policy alone. Storage lifecycle rules are used for large or time-limited data such as media archives.

On payment, the client owns the delivered system, its source code, its infrastructure definitions and its data. Data can be exported in standard formats on request. On exit, under the notice and handover terms of the agreement, Opsenium hands over the repository, the runbook and the Azure resources to the client or another provider.