OASOpen
Architecture
Systems
Back to insights
Three Pillar

Managed Security Shared Responsibility: What OAS Does, What You Keep

A managed security service does not move accountability. Here is how the work splits across Protect, Detect and Recover, and which decisions stay with your business under POPIA.

OAS Editorial Team

· 5 min read

A managed security contract moves a great deal of work to the provider. It does not move accountability. The organisation that holds the personal information remains the responsible party, and some decisions only the business can make.

This guide sets out how the work divides under the OAS Three Pillar managed security service, pillar by pillar: Protect (SentinelOne), Detect (N-able N-central) and Recover (Cove Data Protection). For each one it names what we run and what you keep.

Accountability stays with the responsible party

The Protection of Personal Information Act (POPIA) sets the frame. Section 19 requires the responsible party to secure personal information with appropriate, reasonable technical and organisational measures, and to verify the safeguards regularly. When an operator processes that information on your behalf, section 21 requires a written contract obliging the operator to maintain those measures, and requires the operator to notify you immediately if there are reasonable grounds to believe information has been accessed by an unauthorised person.

Section 22 then puts the duty to notify the Information Regulator and affected data subjects on the responsible party, as soon as reasonably possible after the compromise is discovered.

For a managed security relationship this means three things. The contract should name the measures the provider maintains. The provider must tell you about a suspected compromise without delay. And the decision to notify the Regulator remains yours. A managed service gives you the evidence and the timeline; it cannot make the notification for you.

Protect: we run the agent, you keep the scope

Under the Protect pillar we deploy the SentinelOne agent, set the protection policy, review detections and carry out containment, remediation and rollback where the policy allows it. Three things stay with you.

  • Scope. Protection covers the devices we know about. New laptops, servers built outside the standard process and personal devices used for work are gaps until they are enrolled. Someone on your side needs to own the device list and the joiners and leavers process.
  • Exceptions. When an application is blocked, the request to exclude it comes from the business and carries business risk. We advise and implement; you approve.
  • Rollback expectations. SentinelOne describes its ransomware rollback as relying on the Windows Volume Shadow Copy Service with added protections. It works mainly on Windows, it cannot undo data that has been stolen, and attackers sometimes try to delete shadow copies first. SentinelOne itself recommends keeping regular external backups. Rollback is the fast first path to recovery, not a substitute for the Recover pillar.

Detect: patch rules are a joint decision

Under the Detect pillar we run N-central monitoring, respond to alerts and operate patch management. N-central's automatic approval rules approve or decline patches as they are detected, matching on KB number, title keywords or a CVSS score range. Conflicts are resolved by a strict hierarchy, with device, site and customer rules taking precedence over service organisation rules, and a declined status outranking an approval at the same level. A rule set that is not designed deliberately can approve at one level what it declines at another.

The rules are ours to build and maintain. The inputs are yours.

  • Maintenance windows. Patches install in the scheduled window unless a rule is set to install immediately, which ignores the schedule and does not notify users. You decide which systems may reboot when.
  • Pilot groups. A delay between detection and approval gives a small group of devices time to surface problems. You nominate who sits in that group.
  • Critical systems. Line-of-business servers and anything with a vendor-certified configuration need their own rules. We only know which these are if you tell us.

The cyber resilience metrics article explains how to report on patch coverage and detection times once these decisions are settled.

Recover: you set the targets, we prove the restores

Under the Recover pillar we configure Cove Data Protection, monitor backup health and run restores when they are needed. Cove's Recovery Testing service creates a virtual machine from the latest backup every 14 or 30 days, boots it and sends a boot screenshot to the console. The test needs no local hardware and the virtual machine is purged afterwards. It is available for Windows devices on Backup Manager 17.4 or later with the virtual disaster recovery feature enabled.

A boot screenshot is strong evidence that a backup is restorable. It does not tell you whether the right data was selected, whether retention meets your obligations, or whether the server could be rebuilt in time. Those are your decisions.

  • Selection and retention. Which folders, databases and Microsoft 365 workloads are backed up, and for how long, follow from your legal and operational requirements. We implement the selection; you confirm it is complete.
  • Recovery objectives. The recovery time and recovery point objectives for each service come from the business. Protect, Detect, Recover in Practice describes the deployment order; the targets have to exist before the schedule is set.
  • Restore priority. The order in which systems come back after an incident is a business call. Agree it in advance.
  • Reviewing the evidence. Recovery Testing results and restore reports are only useful if someone on your side reads them. Put them on a monthly review agenda.

A responsibility matrix to sign off

Before the service goes live, write the division down. For each line, name the owner on both sides.

  1. Device inventory and enrolment, including joiners and leavers.
  2. Security policy exceptions and application exclusions.
  3. Patch maintenance windows, pilot groups and critical-system rules.
  4. Backup selection, retention periods and recovery objectives.
  5. Restore priority order for the main business services.
  6. Incident communication: who we call, and who decides on Regulator and customer notification.
  7. Administrative accounts in Microsoft 365 and Entra ID, which stay under your control.
  8. Review cadence for reports, recovery-test results and open exceptions.

None of this reduces what a managed service takes off your plate. It makes sure the parts that cannot be outsourced have a name against them, which is what an auditor will ask to see.

Sources

Agree the division of responsibility before go-live with the OAS Three Pillar service.

Keep exploring

All insights