ISO 27001 for managed service providers and MSSPs

CISA's advisory AA22-131A recommends regularly tested, isolated backups because an attacker who reaches an MSP's management plane can often reach the backups that sit beside it. Isolation means a copy that cannot be altered or deleted using the credentials and network paths that manage production. For an MSP, the question is whether a compromised administrator account at one customer could also destroy the recovery copies for every other customer. Annex A control A.8.13, Information backup, asks the organization to keep and test backups in line with an agreed policy, and A.5.29, Information security during disruption, covers keeping security working when operations are degraded. Auditors will look for a documented backup design that shows where copies live, who can reach them and how that access is separated from daily administration.

An auditor will sample restore test records and check that restores actually completed, not just that backup jobs reported success. Each record should name the system restored, the backup point used, the date, the person who ran the test, the restore duration measured against the recovery objective agreed with the customer, and the result. Failed tests and the corrective actions that followed matter as much as passes. Where an MSP restores into an isolated environment, the record should say so. A.8.13 links backup testing to the organization's own policy, so the evidence is only as strong as the schedule that the policy sets and the sampling that shows the schedule was followed. Confirm with your customers which restore frequency and scope they expect, because contracts often set this more tightly than the standard does.

Backup access logs should show every login, role change, retention change and deletion attempt on backup systems, tied to a named individual or service account. AA22-131A advises that MSP accounts be limited to the systems the MSP manages, audited for use and disabled when not needed or when a contract ends, so the logs should also demonstrate that dormant or departed accounts were removed. Auditors commonly sample a set of accounts, compare them with the access list, and check the approval record for each privileged grant. The MSP should retain logs in a location that the backup administrators cannot edit. Ask your logging platform whether it supports write-once storage and confirm that the retention period matches your contract and any regulator's expectation.

Key and credential custody should sit with a separate control path from the production administrators who could otherwise delete backups. Under AA22-131A, MSP accounts that reach customer environments are treated as privileged and should use multifactor authentication, and backup repositories should not be administered through the same accounts that run daily production work. The contract should state whether the customer, the MSP or a shared process holds encryption keys and deletion rights, and the evidence should show that split. Auditors will test this against the access control and privileged access controls in Annex A, so the access matrix for backup platforms should be documented and reviewed. Confirm with the customer who may authorize a restore, since that decision belongs in the contract as well as the runbook.

Continuity exercise reports should show that the MSP has tested recovery of its own delivery capability, not only individual file restores. A useful report describes the scenario, such as loss of a management plane or a ransomware event affecting a customer tenant, the people and systems involved, the recovery steps taken, the time to recover against agreed targets, and the gaps found with owners and due dates. Annex A continuity controls, including those on ICT readiness for business continuity, expect planned testing and review of results. Auditors will sample exercise reports and follow the findings into later records to check that corrective actions were closed. Ask your implementation partner to help design scenarios that cover shared infrastructure, since a single-customer test rarely shows cross-customer risk.

An MSP can prepare this evidence itself if it has the staff time, a documented backup design and a tested restore process, and many do. Outside help is usually needed when the design must be reviewed for isolation, when backup platforms need hardening or self-hosted deployment, or when evidence collection must be set up so that it runs without manual effort each month. The organization owns its controls and the records. An implementation partner such as DeployOpen can plan, configure and document a self-hosted backup and logging stack inside the client's own infrastructure, and can run restore and continuity exercises as part of a fixed-scope engagement. Only an independent certification body issues the ISO 27001 certificate, so the partner's role ends at preparing systems and evidence. Ask any provider to state in writing which tasks they perform and which remain with your team.

Costs fall into a one-time design and build phase and a recurring operating phase. The one-time work covers architecture of isolated repositories, account separation, logging configuration, and the first full set of restore and continuity exercises. Recurring costs include storage for retained copies, log retention, periodic restore testing, access reviews and staff time for evidence sampling. Storage volume, the number of customer environments, required restore speed, retention periods and whether backups must stay in a specific jurisdiction are the main drivers. No supplied source gives a price for this work, so ask any provider for a quote built from a written scope that lists the systems covered, the restore frequency, the retention periods and the evidence to be delivered. Compare quotes on what is included, not only on total figure.

Usually not in the way the question implies. ISO/IEC 27001 lets an organization narrow its scope by organization, location or service, but it does not allow dropping any requirement in clauses 4 to 10 for a conformity claim. A SOC service can be the defined scope of the ISMS, but the ISMS still has to cover the context, leadership, planning, support, operation, evaluation and improvement that apply to that service, along with the Annex A controls that apply to it. Ask the certification body to explain in writing how it will test the boundary between the certified service and the rest of your business, including shared tooling, shared staff and shared administrator accounts. The boundary decision is yours to document, and the auditor will test whether it matches reality.

The main drivers are the number of people doing work under your control, the number of sites, and how many third parties sit inside the service delivery chain. Under the audit time rules that certification bodies apply, on-site audit time for multi-site organizations is generally calculated from the total number of persons doing work under the organization's control, wherever they are located, so a distributed delivery team increases audit days even when each site is small. Other cost components are the time your own staff spend on risk assessment, supplier reviews and evidence collection, and any outside help you buy. Ask for a quote that lists people in scope by site, the sites to be audited, the supplier list and whether the certification body has separate charges for stage one, stage two and surveillance audits.

Under ISO/IEC 17021-1, a management system certification cycle lasts three years, and the certification body must audit the certified organization in every calendar year of that cycle. In practice this means one audit each year, either a surveillance audit or, in the third year, a recertification audit. Surveillance audits sample the ISMS rather than repeating the full assessment, but they still test access control, supplier management and incident handling, which are high-traffic areas for an MSP. Your own planning should therefore assume an annual audit commitment for the life of the certificate. Confirm with the certification body which audits fall in which calendar year, and how a new site or a new managed service added mid-cycle is handled.

Yes, many organizations run an ISMS internally, but it depends on whether the people who own controls also have time to maintain them. An MSP already operates many of the technical controls for customers, so the gap is often documentation, risk management, supplier oversight and internal audit rather than the technology itself. Internal teams usually need a named owner for the ISMS, a documented risk assessment, a Statement of Applicability that matches what staff actually do, and evidence collected on a routine basis. An implementation partner can help build and test these, but it cannot own the controls, and it cannot be the independent auditor. Be realistic about whether one engineer can manage operational duties and the ISMS together, because the audit will test whether the ISMS runs day to day.

The work needs time from the people who run access, monitoring and customer contracts, not only from the compliance function. Engineers provide the evidence for administrator access, multi-factor authentication, logging and backups, and they must be able to show that accounts used to reach customer environments are limited to the systems they manage, audited and disabled when not needed. Account managers and legal staff own the contract terms that split responsibilities for hardening, detection and incident response, and they must explain in writing which services are and are not included. Ask your certification body and implementation partner to list the evidence requests by role before the engagement starts, so the people involved can plan their time.

Customers usually ask about the supplier controls that apply to a managed provider, which is Annex A control A.5.19 on managing information security risks linked to suppliers' products or services, along with the closely related controls on supplier agreements, the ICT supply chain, monitoring of supplier services and cloud use. Customers also ask how you handle privileged access into their environments, since CISA advisory AA22-131A recommends that managed service providers apply MFA to every account that accesses customer environments and treat those accounts as privileged. Expect questions about isolated, regularly tested backups as well. Prepare a short written statement of which controls you run for customers and which they must run themselves, because that statement often answers the questionnaire before it is sent.

No. A certificate covers the ISMS of the certified organization within its defined scope, which for an MSP is its own service delivery, staff, systems and suppliers. It does not certify the customer's systems, and it does not transfer responsibility for those systems. Contracts still decide who owns hardening, detection and incident response for each customer environment. Ask your certification body to confirm that the certificate scope statement names the services you deliver, and check that customer contracts do not claim broader coverage than the certificate supports.