Skip to content
Public Framework

Layers

v1.0 · in consultation

Operations & Security (OPS)

Layer OPS of Public Framework Modelling Language 1.0 answers the question “How is it operated and protected?”. This page describes the layer's concepts, how they relate, and its 10 element types.

Describes specification v1.0

What the layer describes

The OPS layer answers the question “How is it operated and protected?”. It describes technical operation and recovery: service levels, monitoring, backups, incidents (Incident) and security. Continuity of the public service (PublicService) belongs to CNT.

Concepts and how they relate

A monitor (Monitor) observes an operational condition. Optionally, it triggers an alert rule (AlertRule), and the rule triggers a runbook (Runbook). The relationship is “triggers” (triggering) and connects behaviours and events.

Optionally, a security control (SecurityControl) and a backup policy (BackupPolicy) mitigate risks (Risk), through the “mitigates” relationship (mitigates). So does a disaster recovery plan (DisasterRecoveryPlan), which restores technical systems after a severe disruption. The target of the relationship is a risk, a disruption scenario (DisruptionScenario) or a vulnerability (Vulnerability).

An incident or a vulnerability affects the exposed elements, for example a software system (SoftwareSystem) or a node (Node). The relationship is “affects” (affects).

Element types

The layer has 10 element types, in these families: behaviour (3), information (3), event (3), intent (1). Each type's own fields are listed under its definition; the fields common to every element are described under the core concepts.

  • ServiceLevelAgreementService level agreement · information family

    An agreement defining operational service-level commitments.

    Key attributes: availabilityPercentresponseTimesupportHours
  • MonitorMonitor · behaviour family

    A mechanism or definition for observing an operational condition.

    Key attributes: kindtoolregionhorizonProfileexternalReferencemonitorKindsignalqueryobservesverifiesControlsserviceLevels
  • AlertRuleAlert rule · event family

    A condition that raises an operational alert.

    Key attributes: conditionseverityregionhorizonProfileexternalReferenceincidentSeveritymonitorsresponse
  • RunbookRunbook · behaviour family

    An operational procedure for handling a defined situation.

    Key attributes: regionhorizonProfileexternalReferencepreconditionsprocedureverificationrollbackappliesTo
  • BackupPolicyBackup policy · information family

    A policy defining backup coverage, scheduling and retention.

    Key attributes: frequencyretentioncoversregionhorizonProfileexternalReferencemethodbackupSubjectsdestinationrunbook
  • DisasterRecoveryPlanDisaster recovery plan · information family

    A plan for restoring technical systems after a serious disruption.

    Key attributes: rtorpolastTestedOncoversregionhorizonProfileexternalReferenceproceduretestOutcometestedAtrestoresbackupPoliciesrunbooksrecoveryLocation
  • IncidentIncident · event family

    A recorded operational disruption and its handling.

    Key attributes: severitystartedAtresolvedAtreportedToCsirtAtregionhorizonProfileexternalReferenceofincidentSeverityopenedAtclosedAtsummarystatusaffectedElementsdetectedByresponseRunbooks
  • SecurityControlSecurity control · intent family

    A safeguard intended to reduce a security risk.

    Key attributes: frameworkReferencekindstatusregionhorizonProfileexternalReferencecontrolKindimplementationprotects
  • VulnerabilityVulnerability · event family

    A weakness that can expose software or infrastructure to harm.

    Key attributes: cveIdcvssScorestatus
  • OperationalScheduleOperational schedule · behaviour family

    A schedule governing recurring operational activity.

    Key attributes: regionhorizonProfileexternalReferenceofcronExpressiontimezonekindcronDialectwindowStartwindowEndtargets

In the “Family support benefit” example

Figure 4.9 (page 37) shows the OPS layer in the example. The recovery plan “Benefits technical recovery” mitigates the risk “Risk of unreconciled paper cases”, from X. The plan brings the software system “Benefits case platform” and its data back into service before the paper applications are reconciled. The monitor “Benefit availability monitor” checks the availability of the channel (ServiceChannel) “Public benefit portal”, from ORG, and of the API (API). The monitor raises an operational alert. The monitor observes the platform, and the plan covers and restores it. These links are fields, which is why the platform does not appear in the figure.

Was this page helpful?