ISO 27001 Control 7.1: Physical Security Perimeters

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

In short: ISO 27001 control 7.1, physical security perimeters, requires defined perimeters around areas that hold information and equipment. For a remote, cloud-first business most perimeters are inherited from cloud providers, landlords and co-working operators; you describe what you inherit, keep the evidence, and secure whatever space you control yourself.

Around eight in ten of the businesses I work with are fully remote and cloud-only. Small technology companies and start-ups, mostly, who need to show good governance over a set-up that lives in AWS, Azure or Google Cloud and on their staff’s laptops. For them, the physical controls in section 7 of Annex A can feel like they were written for somebody else.

In part they were. But excluding them is not the same as ignoring them. When your information sits in someone else’s data centre, or your team works from a co-working space, the perimeter still exists. You have simply inherited it, and an auditor will want to see that you know what you inherited and from whom.

Control 7.1 is the first of the physical controls and sets the pattern for the rest. This page covers what it asks for, how it applies to a remote or co-working business, and how to justify your approach in the Statement of Applicability. There is a free checklist further down that records your inherited controls for all of section 7.

What control 7.1 actually asks for

The control requires security perimeters to be defined and used to protect areas that contain information and other associated assets. In practice:

• Know where your information and equipment are. Offices, comms cupboards, data centres, home offices.
• Define the boundary around each. The building, the floor, the room, the cabinet, or the cloud provider’s facility.
• Make the boundary proportionate to what it protects. A locked comms cabinet for a network switch; much more for a room full of servers.
• Know who provides it. You, your landlord, your co-working provider or your cloud provider.

In the 2013 edition this was control A.11.1.1. The intent is unchanged. What has changed is how few small businesses now have anything inside their own four walls worth a perimeter.

Remote and cloud-only: what applies

If your systems are in the cloud and your staff work from home, much of 7.1 applies somewhere other than your premises. The data centres holding your information have perimeters: fences, guarded entrances, mantraps, cameras. You did not build them, but you rely on them, and that reliance is what you need to record.

Auditors are entirely comfortable with this, provided there is sufficient justification. That means two things. First, a clear statement of what you do and do not have: no office, or an office with no information processing in it, or a co-working desk. Second, evidence that the perimeters you rely on exist, which for a cloud provider is its published assurance: an ISO 27001 certificate or SOC 2 report describing the physical controls at its data centres.

Inherited controls: describe them, do not just assume them

The phrase that matters is inherited controls. When a control is provided by someone else, you have not removed the requirement; you have transferred the work while keeping the responsibility to understand it. For every physical control you rely on someone else for, you should be able to say who provides it and how you know. One point on terminology: most certification bodies expect an inherited control to be marked as applicable in your Statement of Applicability, with a note saying who provides it. Exclusion is for controls where the risk genuinely does not arise for you, such as secure areas when you have none.

• Cloud providers. Their ISO 27001 certificates and SOC 2 reports cover data centre perimeters in detail. Download them, check they cover the services and regions you use, and refresh them annually, exactly as under control 5.19.
• Landlords and co-working providers. Their terms, house rules or security statement should describe building access, out-of-hours security and reception. If nothing is written down, ask them, and keep the reply.
• Your own part. Whatever is left: a locked cabinet, a lockable room, the comms cupboard.

Co-working spaces and shared offices

Lots of organisations work from co-working spaces, and the same principle applies. The landlord controls the front door; you control what happens at your desks. The building perimeter is inherited; anything you store there, and anything you leave on the desk overnight, is yours.

Ask three questions of any shared space. Who can get into the building out of hours? Who can get onto our floor or into our room? Where can we lock things away? The answers, written down, are most of your evidence for 7.1.

Recording inherited and excluded controls in the Statement of Applicability

Where someone else provides a control, mark it applicable and record it as inherited. Where a control genuinely does not apply at all, exclude it and say why. Either way, be specific. A good entry: “Applicable, inherited. No office premises. All information processing is in Microsoft 365 and AWS. Physical security of data centres is inherited from the providers and evidenced by their SOC 2 reports, reviewed annually.” A weak one is “Not applicable: cloud-based”, which tells the auditor nothing.

Partial applicability is common and fine. You may have a small office with a network switch and a printer, but no servers. Then 7.1 applies to the cabinet and the office, and is inherited for everything else.

What auditors will look for

For perimeters, I want to see what you inherit and how you know.

1. Your Statement of Applicability. Is 7.1 included or excluded, and is the justification specific?
2. Where your information is. I will compare your answer with your asset inventory and supplier register.
3. Evidence for inherited perimeters. The cloud provider’s report, and something from your landlord or co-working provider.
4. Anything you protect yourself. If you have an office, I will want to see the boundary that protects your equipment.
5. On site, if I visit. Does what I experience match the documents?

Common issues

• “Not applicable: we are in the cloud”, with no mention of the provider’s controls.
• No evidence held for the data centre or building controls being relied on.
• An office with network equipment and no defined boundary for it.
• Co-working arrangements with no idea who can enter out of hours.
• Cloud reports downloaded once and never refreshed.

The self-check

Start by listing where your information physically lives.

• Where, physically, is your information right now?
• Which perimeters do you rely on that someone else provides?
• Can you produce your cloud provider’s current report describing data centre physical security?
• Who can enter your office or co-working space out of hours?
• Does your Statement of Applicability justify 7.1 in a way an auditor would accept?

When the perimeter fails

In 2014, at the education charity where I worked, we had a small office around the corner from head office: swipe card access, perhaps 30 staff in the building. One morning every laptop that had been left on a desk overnight was gone. The cable locks had simply been broken. IT suddenly had to find and build around ten laptops, and the thief was never caught. It could have been someone inside, or someone who tailgated in one evening behind a person with a card. Nobody could say, because nothing recorded who had come and gone.

Co-working spaces add a twist: the perimeter is shared with people you have never met. In 2019 a tenant at a WeWork building in Manhattan ran scans of the building’s shared Wi-Fi and found 658 devices exposing other tenants’ files, including financial records, contracts and scans of passports and driving licences (reported by Dark Reading). The building was secure; the network inside it was not. If you work from a shared space, treat its network as untrusted and its perimeter as someone else’s control, and record both as inherited.

Holding evidence of what you inherit is where most organisations fall short. Of the roughly 30 organisations I have audited or implemented ISO 27001 for since 2024, around 70% held nothing from their cloud providers: no SOC 2 report, no ISO certificate, nothing beyond an assumption that the provider is secure (see my findings). It is a regular finding, and one of the easiest to fix. Microsoft publishes its reports in the Service Trust Portal and AWS in AWS Artifact; most SaaS providers have a trust or compliance page.

A coaching client told me recently that they could not do any due diligence on a supplier because it was the only one offering the service they needed, so they had no choice. That may be true, but having no choice does not mean you skip the questions. Download what they publish, read it, note the gaps, and record the decision. That is what an auditor wants to see.

How control 7.1 links to other clauses and controls

• Control 7.2, Physical entry. Controls entry through the perimeter.
• Control 7.3, Securing offices, rooms and facilities. What happens inside it.
• Control 5.19, Information security in supplier relationships. Where cloud provider and landlord evidence is managed.
• Control 5.23, Information security for use of cloud services. The cloud side of inherited controls.
• Control 5.9, Inventory of information and other associated assets. Tells you where things are.
• Clause 6.1.3, Information security risk treatment. Where the Statement of Applicability and its justifications are required.

Frequently asked questions

Sources and further reading

Official guidance and standards referred to on this page.

• ISO/IEC 27002:2022. The implementation guidance that accompanies the controls.
• Service Trust Portal. Microsoft’s audit reports and certifications.
• AWS Artifact. AWS compliance reports, including SOC reports.
• Cloud security principles. NCSC guidance, including the physical protection you should expect from a cloud provider.
• AWS data centre controls. How AWS describes the physical security of its data centres.
• Azure facilities and physical security. How Microsoft describes the physical security of its data centres.
• Physical security guidance. National Protective Security Authority guidance on protecting premises.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call