Protecting Against Physical & Environmental Threats and Working in Secure Areas: ISO 27001 Controls 7.5, 7.6

Elena Cho got the call at 4:47 a.m. on a Tuesday in April. She was VP of Infrastructure at Bridgepoint Settlement Services, a Houston-based payments processor that cleared roughly $9 billion a year in ACH and card settlement traffic for regional banks and credit unions. The call was from her on-call network engineer, and the first sentence out of his mouth was one she still repeats to new hires four years later: "Elena, there's water coming through the ceiling of the server room, and I don't know how much."

A storm system had stalled over Harris County for six hours, dumping nearly nine inches of rain. Bridgepoint's primary data center — leased space on the lower level of a converted warehouse building chosen eight years earlier primarily because the rent was cheap — sat nine feet below street grade. The building's storm drainage had been adequate for ordinary Houston rain. It was not adequate for what meteorologists later called a 1-in-40-year event. By 6:15 a.m., four inches of water covered the raised floor. Two of Bridgepoint's three core switches and one of its two settlement database servers were destroyed. The backup generator, sited in the same sub-grade utility room as the primary switchgear, never had the chance to start — it was underwater before the first outage alarm cleared.

Bridgepoint was down for eleven hours. Settlement files queued for three regional banks did not clear on time. The direct cost — emergency hardware, disaster-recovery site activation, contractor overtime, and a negotiated goodwill credit to two banking clients — came to $2.3 million. That number does not include the six months Elena spent explaining to Bridgepoint's board why a company whose entire business model depended on moving other people's money had never asked a basic question: what happens to this room if the ground floor floods?

The flood was the loud failure. Eight months earlier, Bridgepoint had suffered a quieter one that, in Elena's words, "should have been the warning shot that saved us $2.3 million, if anyone had connected the dots." A subcontracted HVAC technician, badged in to service a rooftop unit, was escorted by a facilities employee as far as the mechanical mezzanine — and then left alone for "just a few minutes" while the escort took a phone call. Those few minutes took the technician past an unlocked door into the card-data processing room, where he used his phone to photograph a whiteboard listing failover IP addresses and a rack of servers with asset tags clearly visible, later sharing the images in a group chat with friends as "cool data center stuff." No malicious intent was ever proven, and no fraud was ever traced to the photos. But Bridgepoint's QSA flagged it during the next PCI assessment as a reportable exposure, and the incident response and forensic review cost roughly $180,000 — a bill for a problem that a locked door and a two-minute training video could have prevented for close to nothing.

Two incidents, eight months apart, at the same company. One was a failure to protect a secure area against a physical and environmental threat. The other was a failure to control how people behaved once they were inside a secure area. ISO/IEC 27001:2022 treats these as two distinct, adjacent controls for exactly this reason — Control 7.5, protecting against physical and environmental threats, and Control 7.6, working in secure areas — and this article covers both, because in practice they are two halves of the same discipline: keeping bad things out of the rooms that matter, and keeping the rooms that matter well-behaved once people are inside them.

Who This Is For

This article is for the information security manager, facilities lead, or IT operations manager who owns — or is about to own — the physical protection of server rooms, data centers, network closets, or any other space designated as a secure area under an ISMS. It assumes you already have physical perimeters and entry controls in place, or are building them in parallel, and that you now need to answer two harder questions: what are we protecting this room against, and how do we make sure people behave once they're inside it? You'll walk away with a threat-based framework for Control 7.5, a rules framework for Control 7.6, the specific documentation an auditor will expect for both, real-world failure patterns, and language you can adapt directly into your own physical security procedure.

Where 7.5 and 7.6 Sit in the Physical Controls Family

Annex A's physical theme runs from Control 7.1 through Control 7.14 — fourteen controls covering everything from perimeter fencing to secure disposal of equipment. If you haven't yet mapped the full set, our Physical Controls Overview covering 7.1–7.14 is a useful starting point before diving into any single pair. Controls 7.5 and 7.6 sit in the middle of that sequence, and they build directly on the controls before them.

Controls 7.1 through 7.3 establish the perimeter and the entry mechanics — fences, badges, mantraps, and physical security perimeters and entry controls that decide who gets through the door in the first place. Control 7.4 adds eyes on the space through physical security monitoring — CCTV, intrusion detection, guard patrols. Controls 7.5 and 7.6 then answer two questions those earlier controls don't: what happens to the room itself when something goes wrong that has nothing to do with an intruder (fire, flood, power loss, earthquake), and what are the rules for behavior once someone has legitimately been let inside? Table 1 lays out the full sequence so you can see where this article's scope begins and ends.

It's worth being precise about what each control does and does not require, because auditors will test them separately even though most organizations implement them as one integrated program.

Control 7.5 — Protecting against physical and environmental threats requires that "protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats to infrastructure" be designed and implemented on a risk basis. It's fundamentally about the building and its systems: does the room have fire suppression, does it have flood protection, does it have clean and redundant power, is it sited somewhere that doesn't invite disaster in the first place.

Control 7.6 — Working in secure areas requires that "security measures for working in secure areas" be designed and implemented. It's fundamentally about people: who is allowed to be in the room, how visitors and contractors are supervised while they're there, whether recording devices are permitted, and whether the room is locked and empty when nobody's using it.

"I tell every client the same thing in kickoff: 7.5 protects the room from the world, and 7.6 protects the room from the people you just let into it. Organizations that only build one half of that pair are the ones I see in the incident debrief six months later." — Marcus Whitfield, Director of Physical Security Advisory, Kestrel Risk Partners

The 7.5 Threat Catalogue: What "Physical and Environmental Threats" Actually Means

ISO 27002:2022's guidance on Control 7.5 is deliberately broad, and that breadth is the point — the standard doesn't hand you a fixed list of threats to protect against, because a data center in Miami and a network closet in Minneapolis face genuinely different risk profiles. What it asks for instead is a risk-based process: identify the physical and environmental threats relevant to each secure area, based on its location, its contents, and its role in the business, and implement proportionate protection against each one.

In practice, after fifteen years of walking client facilities and reading disaster-recovery post-mortems, the threats sort into five recurring categories. Table 2 is the catalogue I use on every physical security assessment, and it's a reasonable starting checklist for your own risk register.

Table 2: The Physical & Environmental Threat Catalogue

A few of these deserve more than a table cell, because they're where most of the compliance gaps I find actually live.

Fire Protection: Detection, Suppression, and Compartmentalization

Fire is the threat every organization already half-plans for, because building codes generally require some baseline provision — and that's precisely why it's the one most often under-protected relative to what a secure area actually needs. A code-minimum wet-pipe sprinkler system satisfies the fire marshal. It does not satisfy an auditor asking how you protect a room full of servers from the water damage a sprinkler discharge would itself cause, which is why data centers and server rooms typically layer three things instead of relying on sprinklers alone.

First is early detection — VESDA-style aspirating smoke detection or ionization detectors calibrated for the low particulate density of an electrical fire, which triggers an alarm well before a fire is large enough to trip a conventional heat-activated system. Second is clean-agent suppression — FM-200, Novec 1230, or inert-gas systems that extinguish fire by removing oxygen or disrupting the combustion chain without leaving a corrosive or conductive residue on electronics, unlike water or standard dry chemical extinguishers. Third is compartmentalization — fire-rated walls, doors, and penetration seals around cable runs that stop a fire in an adjacent space (a break room, a storage closet, a neighboring tenant's suite) from spreading into the secure area before it's contained.

Handheld extinguishers still matter, but placement and type matter more than most facilities managers realize. A CO2 or clean-agent extinguisher belongs inside a server room; a standard ABC dry-chemical extinguisher does not, because the residue it leaves behind can ruin equipment that the fire itself never touched. I've walked into more than one otherwise well-run data center where the only extinguisher in reach of the room was the wrong chemistry entirely — a five-minute fix once someone notices it, and a genuine safety and asset-protection gap until they do.

Table 6 lays out the layered set of detection and suppression measures side by side, with the trade-off each one carries, so you can match the measure to the room rather than defaulting to whatever the fire marshal minimally requires.

Table 6: Fire Protection Measures — Detection and Suppression Options

Flood and Water Damage: The Threat Most Often Discovered Too Late

Water is the threat category most likely to be missing entirely from a risk register, because unlike fire it usually has no code-mandated baseline forcing anyone to think about it — which is exactly the gap that cost Bridgepoint $2.3 million. Protecting against water damage starts with a decision made once, at the beginning: siting. A secure area below grade, on a ground floor in a flood zone, or directly beneath a roof, mechanical room, or restroom stack, inherits water risk that no amount of downstream mitigation fully offsets. Where relocation isn't realistic — leased space, a legacy building, a facility chosen for other sound business reasons — mitigation has to compensate: raised flooring with sub-floor water sensors wired to the building management system, positive drainage away from the room rather than toward it, moisture barriers on any wall shared with a wet space, and — critically — physical separation between water-bearing infrastructure (fire sprinkler mains, condensate lines, plumbing risers) and the electrical and IT equipment those systems are meant to protect.

The Bridgepoint case illustrates a second, less obvious lesson: co-location of failure points. Their backup generator sat in the same low-lying utility room as the equipment it was meant to protect, so the same flood that killed the primary systems also killed the failover. A genuinely resilient design puts backup power, in particular, somewhere the same physical event can't reach — a lesson that connects directly to redundancy of information processing facilities under Control 8.14, which we'll return to later in this article.

Power: From Surge Protection to Full Site Redundancy

Power threats range from a momentary brownout that a decent UPS absorbs without anyone noticing to a total grid failure that takes down an entire region. Control 7.5's job is to make sure the protection scales to the consequence: an uninterruptible power supply sized to bridge the gap until generators start, generators sized and fuel-contracted to run the full critical load for the expected outage duration, automatic transfer switches tested — not just installed — on a schedule, and surge protection at the service entrance to prevent a lightning strike or grid transient from destroying equipment outright.

Supporting utilities — power, but also water, gas, and telecommunications feeds into the building — are technically the subject of a separate control, Control 7.11 supporting utilities within the equipment security family, and the two controls overlap deliberately: 7.5 asks whether you've assessed power loss as an environmental threat to the secure area, and 7.11 asks whether the utility infrastructure itself is protected and resilient. An auditor testing one will usually ask about the other in the same breath, so it's worth documenting them together even though they're scored as separate Annex A entries in your Statement of Applicability.

Table 7 sets out the main power-resilience options together, since most implementations end up layering several of them rather than picking just one.

Table 7: Power Resilience Options

Environmental Controls: Temperature, Humidity, and Particulates

Climate control gets treated as a facilities-management afterthought far more often than it should, given how directly it affects hardware reliability. Server and network equipment has documented operating ranges for temperature and relative humidity, and drift outside those ranges doesn't cause a dramatic failure — it causes a slow one, in the form of premature component failure, thermal throttling, and, at the humidity extremes, either static discharge damage (too dry) or condensation and corrosion (too wet). ASHRAE's widely used data center guidance recommends a operating envelope in roughly the 64–80°F range with humidity controlled to avoid both extremes, and while the exact numbers depend on your equipment manufacturers' specifications, the principle that matters for Control 7.5 is redundancy: N+1 cooling capacity, so that a single CRAC unit failure doesn't take the room out of its operating range before anyone can respond, and environmental monitoring with alerting, not just a thermostat someone glances at during a walkthrough. Table 8 translates that guidance into the ranges and monitoring approach I check for during a walkthrough.

Table 8: HVAC & Humidity Control Parameters

Particulate and dust control matters more in industrial or older-building environments than most people expect. Positive-pressure rooms with filtered air intake keep contaminants from migrating in through door gaps and cable penetrations; without it, dust accumulation on equipment intakes gradually restricts airflow and raises internal temperatures in exactly the slow, hard-to-diagnose way that climate drift does.

Environmental protection only works if drift gets detected before it becomes a failure, which is why the sensor layer matters as much as the mechanical systems it watches. Table 9 rounds up the sensor types that typically feed a data center's building management system across the threat categories covered so far.

Table 9: Environmental Monitoring & Sensors

Natural Disaster and Siting: The Decision You Only Get to Make Once

Earthquake, hurricane, tornado, and wildfire risk are geographic facts you can't engineer away — you can only design around them or choose not to be exposed to them in the first place. That's why siting decisions deserve their own line of thinking within Control 7.5, separate from the equipment-level protections above. A secure area in a seismic zone needs structural bracing for racks and raised flooring rated for the expected ground motion, not just a building that meets code for occupant safety. A facility in a hurricane or tornado corridor needs a documented evacuation and shutdown procedure that accounts for the lead time those events actually give you — hours for a hurricane, minutes for a tornado — and, ideally, a secondary site outside the same weather system's reach. A wildfire-prone location needs defensible space around the building and an understanding of how smoke infiltration, not just flame, affects sensitive equipment and air handling.

Table 10 condenses the siting factors above into a quick do's-and-don'ts reference — the questions I ask before a client signs a lease, or revisits one they've already signed.

Table 10: Data-Center Siting — Do's and Don'ts

None of this means every organization needs a bunker. It means the risk assessment that feeds your Statement of Applicability has to actually ask the geographic question — "what does this location expose us to that a different location wouldn't?" — rather than defaulting to whatever building was available and affordable at the time, which is precisely the decision Bridgepoint never revisited in eight years of operating from the same sub-grade space.

Malicious and Intentional Physical Threats

The threat catalogue above ends with the category most easily forgotten because it doesn't show up in a facilities inspection: threats where a person, not weather or infrastructure failure, is the cause. Sabotage by a disgruntled employee or departing contractor, bomb threats against corporate or government facilities, civil unrest that puts a building in the path of protest or looting, and targeted vandalism against known data center or telecom infrastructure all fall under Control 7.5's "intentional... physical threats to infrastructure" language.

Protection against this category leans heavily on controls covered elsewhere — the access restrictions in physical security perimeters and entry controls (7.1–7.3) and the detection capability in physical security monitoring (7.4) — but 7.5 adds the response-planning layer: a documented bomb-threat procedure, a civil-unrest contingency that might include early closure or remote-work activation, and threat intelligence feeds (tied to threat intelligence under Organizational Control 5.7, if your organization has implemented it) that give facilities and security teams advance warning of scheduled protests, labor actions, or regional instability near a physical site.

"Everybody budgets for the fire panel. Almost nobody budgets for the fifteen minutes it takes to write down what security does if there's a credible bomb threat against the building next door. That gap shows up as a blank stare in about one in three tabletop exercises I run." — Renata Ibsen, Principal Consultant, Ibsen Continuity Group

Protections by Threat Type: A Full Reference Table

Table 3 consolidates the threat catalogue with concrete detection, prevention, and response measures — the level of detail I'd expect to see reflected, in some form, in a mature organization's physical security risk treatment plan.

Table 3: Protection Measures by Threat Type

This is also the table I'd point an auditor to directly, because it demonstrates the risk-based reasoning ISO 27002's guidance for Control 7.5 explicitly asks for — not a generic "we have fire extinguishers" statement, but a documented line from threat, to measure, to the continuity and recovery mechanism that takes over if the measure fails.

Tying 7.5 to Continuity, Utilities, and Redundancy

Control 7.5 does not stand alone, and treating it as though it does is one of the most common scoping mistakes I see. Its job is prevention and mitigation at the facility level — stopping or limiting the physical event. But no set of environmental controls has a 100% success rate, which is exactly why ISO 27001 builds a second layer behind it.

Information security during disruption (Control 5.29) and ICT readiness for business continuity (Control 5.30) pick up where 7.5's prevention leaves off: given that a fire, flood, or power event has happened despite your controls, how does the business keep operating? Redundancy of information processing facilities (Control 8.14) and its companion capacity management control (8.6) supply the mechanism most often used to answer that question at the infrastructure level — a secondary site, geographically separated, capable of absorbing the workload if the primary is lost. Bridgepoint's post-incident remediation program, notably, didn't stop at fixing the flooded room; it included standing up a warm-standby processing environment in a different flood zone entirely, specifically because the board understood, for the first time, that 7.5 controls reduce probability but 5.30 and 8.14 controls determine what happens when probability loses.

The practical takeaway for your implementation: don't let Control 7.5 documentation live in isolation in your Statement of Applicability. Cross-reference it explicitly against your business continuity plan and your redundancy architecture, and make sure the risk assessment that justifies your 7.5 controls is the same risk assessment your continuity planning draws from. Auditors increasingly test this linkage directly, asking to see that the physical threats identified under 7.5 appear as disruption scenarios in the 5.29/5.30 continuity documentation — not two disconnected paperwork exercises maintained by two different teams who've never compared notes.

Case Study One: The Cost of an Unexamined Assumption

Bridgepoint Settlement Services' flood, described at the top of this article, is worth returning to with the numbers laid out plainly, because the remediation is as instructive as the failure.

The exposure: A primary data center sited nine feet below street grade, in a leased building never assessed for flood risk, with backup power co-located with the primary systems it was meant to protect.

The cost: $2.3 million in direct losses — hardware replacement, DR site activation, contractor overtime, and client goodwill credits — plus eleven hours of settlement downtime affecting three banking clients.

The remediation, completed over the following nine months: a geotechnical and flood-risk reassessment of the facility (which confirmed the building sat in a 100-year floodplain that had simply never been checked at lease signing); relocation of primary processing to a ground-floor facility outside the floodplain; installation of a warm-standby environment in a geographically separate data center, satisfying both Control 8.14 redundancy and the continuity requirements of 5.29/5.30; and a formal, board-approved physical risk register requiring annual re-assessment of every facility housing information processing equipment.

The outcome: Bridgepoint's next major regional storm event, eighteen months later, caused zero processing downtime. The cost of the remediation program — roughly $640,000 in one-time capital and site transition costs — was, in Elena Cho's later words to her board, "less than a third of what one bad Tuesday cost us the first time."

"The flood didn't teach us that water is dangerous. Everyone already knew that. It taught us that nobody had ever actually asked, formally, on paper, whether our specific building was exposed to it. That's the gap 7.5 exists to close." — Elena Cho, VP of Infrastructure, Bridgepoint Settlement Services (fictional composite case study)

Control 7.6: Working in Secure Areas

If Control 7.5 is about the building, Control 7.6 is about the people inside it — and it's the control most often shortchanged in ISO 27001 implementations because it doesn't map neatly to a purchase order the way fire suppression or a generator does. There's no vendor selling "working in secure areas compliance" as a line item. It's built entirely from procedure, training, and enforcement, which makes it cheap to implement well and easy to implement badly.

ISO 27002's guidance for Control 7.6 groups the requirement into a handful of consistent themes: secure areas should only be used for their intended purpose; only personnel with a genuine need should know a secure area exists or what it's used for; unsupervised working in secure areas should be avoided both for safety and to prevent malicious activity; vacant secure areas should be physically locked and periodically checked; and recording equipment — cameras, audio recorders, and increasingly, smartphones capable of both — should not be permitted inside a secure area without prior authorization. Bridgepoint's HVAC-technician incident, described at the top of this article, is a near-perfect illustration of what happens when an organization has invested heavily in Control 7.5's physical protections but has never written down a single rule under Control 7.6.

Not every secure area carries the same sensitivity, and Control 7.6's rules should scale accordingly. Table 11 sketches a simple tiering model I use to help clients decide how strict a given room's rules need to be before drafting the policy language.

Table 11: Secure-Area Classification Tiers

Who May Work There

The starting point for Control 7.6 is a defined population: a documented list, by role or named individual, of who is authorized to work unsupervised inside each secure area, distinct from the broader population who may simply be granted entry under Control 7.2. Entry and working authority are not the same thing — a facilities manager might legitimately need entry to check a fire panel without ever needing standing authority to "work" among live production servers. Conflating the two is a common gap: organizations that carefully control who badges in rarely apply the same rigor to who is allowed to sit down at a workstation, plug in a laptop, or perform maintenance once inside.

Supervision of Visitors and Third Parties

Anyone without standing working authority — vendors, auditors, contractors, job candidates on a facility tour — needs continuous escort while inside a secure area, not a badge-in-and-walk-away arrangement. "Continuous" is doing real work in that sentence: Bridgepoint's incident happened during a gap of a few minutes, not a few hours, which is the pattern I see most often in escort failures. The fix isn't usually more policy language; it's operational — a rule that an escort who must step away hands off to another authorized staff member or ends the visit, full stop, no exceptions for "just a few minutes."

Not every non-employee category needs identical handling, though — the escort, recording, and logging expectations reasonably differ by who's in the room and why. Table 12 breaks that out by visitor type.

Table 12: Visitor & Third-Party Supervision Matrix

Prohibiting Unauthorized Recording and Photography

Smartphones have made this the fastest-growing gap in secure-area procedures over the past decade, because a "no cameras" sign written for the era of handheld camcorders doesn't obviously cover a phone in someone's pocket. A current policy needs to explicitly name phones, smartwatches, and any other personal recording-capable device, state the exceptions (a documented, approved need — say, an auditor photographing a control for evidence, or a vendor inspecting labeled equipment) and the process for granting one, and be reinforced by visible signage at every entry point. Enforcement matters more than wording: a policy nobody explains during badge issuance or visitor sign-in is a policy that exists only on paper, which is exactly the position Bridgepoint was in when its contractor's phone came out.

Keeping Secure Areas Locked and Empty When Unattended

A room with excellent access control that's routinely propped open "because people are in and out all day" has, in practice, no access control at all during those hours. Control 7.6 expects secure areas to default to locked, with doors closing and latching automatically rather than relying on someone remembering, and to be checked — physically, on a documented schedule — to confirm they're empty and secured outside of working hours. This is a low-cost, high-value control: door-closer hardware and a nightly walkthrough checklist cost far less than almost anything else in this article, and catch the kind of casual propped-door habit that undermines every other investment in the room.

Need-to-Know Awareness of the Secure Area's Existence

The subtlest element of Control 7.6, and the one most often skipped, is discretion about the room's existence and purpose in the first place. A server room clearly labeled "Data Center" on a building directory, or a card-processing room visible through interior glass from a general-access hallway, advertises a target to anyone walking through — employee, visitor, or delivery driver — who has no need to know it's there. Good practice treats the existence and function of a secure area as need-to-know information: unmarked or generically labeled doors, no reference to the room's sensitivity in publicly visible signage or building directories, and internal communications about the space limited to those with an operational reason to know.

Table 4 summarizes the working-in-secure-areas rule set as a quick-reference for policy drafting.

Table 4: Working-in-Secure-Areas Rules at a Glance

"The smartphone problem is the one every client thinks doesn't apply to them, right up until I ask their front-desk staff what the visitor policy says about phones and get three different answers from three different shifts." — Priya Nandakumar, Lead Physical Security Auditor, Sentinel Assurance Group

Tying 7.6 to Entry Controls, Monitoring, and Awareness Training

Control 7.6 rules are only as strong as the enforcement mechanisms behind them, which is why the control connects directly to three others already covered elsewhere in this series. Physical security perimeters and entry controls (7.1–7.3) determine who can badge into the secure area in the first place — 7.6 governs what happens after they're in. Physical security monitoring (7.4) provides the CCTV coverage and alarm response that turns a "no unsupervised access" rule from an honor system into something enforceable, and gives you the forensic record to review after an incident like Bridgepoint's. And security awareness, education, and training (Control 6.3) is the mechanism that actually gets these rules into people's heads — a written policy that nobody covers during onboarding or visitor check-in is, functionally, a policy that doesn't exist.

The practical lesson from watching this fail repeatedly: don't treat 7.6 as a standalone policy document. Build it into your visitor sign-in script, your contractor badge-issuance checklist, and your annual security awareness refresher, so the rule is delivered at the moment someone actually needs it rather than buried in a policy library nobody opens.

Evidence for Auditors: What to Have Ready

An assessor testing Controls 7.5 and 7.6 will ask for a mix of design documentation, records, and live observation. Table 5 lists what I bring to a mock audit for these two controls, organized by which control it primarily supports.

Table 5: Audit Evidence Checklist for Controls 7.5 and 7.6

Auditors consistently tell me the single fastest way to fail this pair of controls in an assessment is having strong documentation with no corroborating log — a beautifully written recording-device policy, for example, with no visitor sign-in record ever asking anyone to acknowledge it. Design documents establish intent; logs establish that the control actually operated.

Common Mistakes I See Across Controls 7.5 and 7.6

Treating siting as unchangeable. Organizations frequently inherit a facility — through a lease signed years earlier, an acquisition, or a legacy headquarters — and never formally revisit whether the building itself is an acceptable risk, as Bridgepoint didn't for eight years. Siting should be reassessed whenever a facility begins housing higher-value information processing than it was originally chosen for.

Co-locating primary and backup systems. Backup power, backup connectivity, and failover equipment sited in the same room, floor, or even building as the primary systems they're meant to protect defeats the purpose of redundancy the moment a facility-wide event occurs — exactly what happened to Bridgepoint's generator.

Writing a recording-device policy that predates smartphones. A "no cameras" sign that never mentions phones is a policy with a hole in it large enough for every visitor who walks through the door.

Confusing entry authorization with working authorization. Badge access answers "can this person get in." It doesn't answer "should this person be left alone in here," which is a distinct question Control 7.6 requires you to answer separately.

No escort handoff procedure. Escort policies routinely specify that visitors must be escorted, but rarely specify what happens when the escort needs to step away — leaving a judgment call to whoever's on shift that day, which is exactly the gap that produced Bridgepoint's photography incident.

Labeling the room. A door sign that says "Server Room," "Data Center," or "SOC" broadcasts the room's purpose to anyone with no need to know it — contractors, delivery staff, building tenants — undermining the need-to-know principle Control 7.6 asks for.

Fire suppression chosen for code compliance, not equipment protection. A wet-pipe sprinkler system satisfies a fire marshal but can destroy exactly the equipment it's meant to save if it discharges; clean-agent systems cost more but protect the asset, not just the building.

No cross-reference between the physical risk assessment and the business continuity plan. Physical threats identified for Control 7.5 that never appear as disruption scenarios in the Control 5.29/5.30 continuity documentation represent a planning gap that surfaces, painfully, during the first real incident.

Case Study Two: Working in Secure Areas at a Regional Cloud Provider

A mid-sized cloud hosting provider — call it Meridian Cloud Systems, serving primarily healthcare and legal-sector clients from a single regional data center — passed its Stage 2 certification audit with a clean bill of physical security, including a well-documented Control 7.5 program with tested fire suppression and dual-utility power. Eleven months later, a routine internal audit turned up a different problem entirely under Control 7.6: an evening cleaning contractor, who had legitimate facility access for common areas, had been let into the server room itself by a night-shift operator "to save time" rather than cleaning around the locked door as procedure required.

No data was confirmed stolen and no equipment was damaged. But the internal audit team could not produce any record of who else, over what period, might have received the same informal access — because there was no working-authority list distinct from the facility's general access roster, and no log of exceptions like this one. The finding was classified as a major nonconformity heading into the next surveillance audit: not because of what happened, but because the organization had no way to demonstrate what hadn't happened.

Meridian's remediation, completed in six weeks, included a documented working-authority list separate from general facility access, a hard technical restriction removing the night-shift operator's ability to grant ad hoc entry, and a revised cleaning contract requiring server-room areas to be serviced only during escorted, scheduled maintenance windows. The surveillance audit six months later closed the finding with no repeat observations, and Meridian's internal audit lead now cites the case in every new-hire physical security briefing.

"The scariest nonconformities aren't the ones where something bad definitely happened. They're the ones where you genuinely can't prove it didn't. That's what an undocumented working-authority list gets you." — Devon Okafor, Internal Audit Manager, Meridian Cloud Systems (fictional composite case study)

Case Study Three: Seismic Risk and a Late Siting Correction

A logistics and freight-forwarding company — Calder Freight Solutions — operated a regional network operations center out of a leased office in a moderate seismic zone on the U.S. West Coast, in a building constructed before current seismic retrofit standards applied to its class of occupancy. The company's ISO 27001 gap analysis, performed ahead of initial certification, flagged the absence of any seismic consideration in its Control 7.5 risk assessment — server racks were free-standing, not braced, and raised flooring was installed without seismic-rated pedestals.

Rather than relocate — a six-figure undertaking with lease penalties Calder's finance team wasn't prepared to absorb mid-cycle — the company opted for targeted mitigation: seismic bracing kits for all racks (roughly $38,000 installed), replacement of raised-flooring pedestals with seismic-rated hardware, and a revised business continuity plan explicitly naming earthquake as a disruption scenario with a defined failover to a secondary facility 400 miles inland, satisfying the ICT readiness expectations of Control 5.30. A magnitude 5.1 earthquake eighteen months later — close enough to rattle the building and trigger an evacuation — caused zero equipment displacement and no data center downtime. Calder's auditor cited the bracing retrofit specifically as an example of proportionate, risk-based control implementation during the next surveillance visit.

"We didn't need a new building. We needed forty thousand dollars of bracing and an honest conversation about what our risk assessment had been ignoring for six years." — Sam Iversen, Facilities & Security Manager, Calder Freight Solutions (fictional composite case study)

Visualizing the Layered Model

The cleanest way I've found to explain Controls 7.5 and 7.6 to a board or an executive sponsor who isn't going to read Annex A is as two concentric layers of protection around the same room — an outer layer of environmental and infrastructure controls, and an inner layer of behavioral rules that only matter once someone has legitimately gotten past the outer layer.

The diagram is deliberately simple: the outer ring keeps disasters and infrastructure failures from reaching the room; the inner ring governs what happens to information and equipment once people are legitimately standing inside it. A gap in either ring compromises the asset at the center, regardless of how well the other ring is built — which is exactly the lesson Bridgepoint learned twice, eight months apart.

How This Pair Compares Across Frameworks

If your organization is also pursuing or maintaining other frameworks, Controls 7.5 and 7.6 have close analogues worth mapping, both to avoid duplicate work and to strengthen your narrative to auditors that these aren't isolated ISO requirements but recognized industry practice. SOC 2's environmental protection expectations under the Common Criteria cover substantially the same ground — fire, flood, power, and climate protection for systems supporting the service commitments in scope. PCI DSS's physical security requirements go further in one specific area relevant to Control 7.6: mandatory video monitoring and physical access logging for anyone handling cardholder data environments, which is worth cross-referencing if your organization is also PCI-scoped, as Bridgepoint was. And the NIST Cybersecurity Framework's Protect function includes physical and environmental protection as an explicit category, giving organizations that report against NIST CSF a natural bridge for describing the same control set in a different framework's language.

Table 13 maps the individual sub-topics within 7.5 and 7.6 against their nearest equivalents in each framework, which is the level of detail I'd expect in a cross-framework compliance matrix rather than a one-line "these are similar" statement.

Table 13: Cross-Framework Mapping for Controls 7.5 and 7.6

None of these frameworks make your ISO 27001 certification redundant, and ISO 27001 doesn't substitute for whatever regulatory obligations those frameworks address — the certification demonstrates that your ISMS manages these risks systematically, which supports but does not replace sector-specific compliance obligations like PCI DSS for card data or HIPAA for health information.

The Business Case: Why This Pair Pays for Itself

It's tempting to file Controls 7.5 and 7.6 under "cost of doing business" — necessary spending that satisfies an auditor and nothing more. That framing undersells them. Bridgepoint's $640,000 remediation program prevented a repeat of a $2.3 million loss within eighteen months; that's not a compliance expense, that's one of the better-returning capital projects the company ran that year. Calder Freight's $38,000 seismic retrofit protected a facility that would have cost vastly more to relocate or rebuild after a genuine structural event. And in every renewal conversation I've sat in on with cyber-insurance underwriters, documented physical and environmental risk management — the kind that Controls 7.5 and 7.6 formalize — is one of the first things underwriters ask about, because facility-level losses (fire, flood, extended power outages) are among the costliest categories of claim they pay out.

There's a sales dimension too, particularly for organizations like Bridgepoint or Meridian Cloud Systems whose customers are themselves handling regulated data. Being able to describe, specifically and with evidence, how your secure areas are protected against fire, flood, and power loss — and how visitors and contractors are prevented from wandering through them unsupervised — is a differentiator in vendor security questionnaires and due-diligence calls that most competitors answer with vague reassurance instead of documentation.

The controls documented properly also make your Statement of Applicability meaningfully stronger, because 7.5 and 7.6 are exactly the kind of controls where a generic "implemented" checkbox invites auditor scrutiny — showing your reasoning, threat by threat, is what turns a compliance document into a credible risk management narrative. If your team is still building fluency with Annex A terminology across the physical theme, our ISO 27001 glossary of terms is a good shared reference to circulate before your next internal audit.

Getting Started: Your Next Steps

If you're building or auditing this pair of controls for the first time, start with the risk assessment, not the equipment list — you can't proportion fire suppression, flood protection, or working-area rules correctly until you know what you're protecting and what specifically threatens it in your specific location. From there, our Annex A — All 93 Controls at a Glance cheat sheet gives your team a fast reference for how 7.5 and 7.6 fit alongside the other 91 controls you're implementing in parallel, and The Complete ISO 27001 Implementation Guide walks through sequencing physical controls against the rest of your ISMS build.

Once your policies and procedures are drafted, cross-check them against our ISO 27001 Mandatory Documents Checklist to confirm you've captured everything an auditor will expect to see documented, and use the Internal Audit Checklist to test your own program — including a walkthrough that checks whether secure areas are actually locked, labeled discreetly, and staffed with an enforced escort policy, not just documented as if they are. And if you haven't yet mapped where your physical controls stand against the full Annex A set, PentesterWorld's ISO 27001 Gap Analysis Tool is built to surface exactly this kind of gap — the unexamined assumption about a building's flood risk, or the recording-device policy that never got updated for smartphones — before an external auditor finds it for you.

Bridgepoint didn't need a bigger budget to prevent either of its incidents. It needed someone to ask, in writing, what could go wrong in that specific room, and what the rules were for the people standing in it. That's the whole of Controls 7.5 and 7.6, and it's within reach of any organization willing to do the asking before the water starts rising.