Annex A 7.6: Working In Secure Areas
Annex a 7.6: working in secure areas requirement means you must define what “secure areas” are in your environment and enforce disciplined behaviors inside them (people, devices, media, conversations, and work practices) so sensitive information is not exposed. Operationalize it by mapping secure areas, setting rules for working there, training staff, and retaining repeatable evidence that the rules are followed. 1
Key takeaways:
- Define and document “secure areas” based on where sensitive work happens, not just where locks exist. 2
- Implement enforceable working rules inside secure areas (clear desks, screen controls, escorting, device restrictions, authorized maintenance). 1
- Make it auditable: keep access lists, visitor/escort logs, training records, inspections, and exception approvals tied to each secure area. 2
Secure areas fail in predictable ways: the door controls are strong, but the work practices inside the room are loose. Annex A 7.6 focuses on that gap. It pushes you to control day-to-day behaviors where sensitive processing occurs, such as data centers, network closets, security operations spaces, records rooms, labs, payment processing areas, and executive spaces where confidential discussions happen.
For a Compliance Officer, CCO, or GRC lead, the fastest route is to treat this as a scoped “micro-program” with three deliverables: (1) a secure area register that defines boundaries and owners, (2) a working-in-secure-areas standard that is specific enough to enforce, and (3) routine evidence capture that proves the standard operates. Auditors will look for consistency: the policy says one thing, badges and visitor handling do another, and staff interviews reveal a third.
This page translates the annex a 7.6: working in secure areas requirement into concrete steps you can assign to Facilities, IT, Security, and People Ops, with artifacts you can retain for ISO 27001 readiness and ongoing assurance. 2
Regulatory text
Provided excerpt: “ISO/IEC 27001:2022 Annex A control 7.6 implementation expectation (Working In Secure Areas).” 1
Operator meaning (what you must do):
- Identify secure areas (physical or logically restricted spaces) where sensitive information is processed, stored, discussed, or where critical systems are administered. 2
- Define acceptable working practices inside those areas (behavioral and procedural rules), then communicate, enforce, and periodically verify them. 1
- Demonstrate operation with evidence that is repeatable and reviewable, not dependent on “we always do that.” 2
Plain-English interpretation
Annex A 7.6 expects you to control what people do while they work in secure areas: how they handle screens, paper, removable media, devices, calls, visitors, maintenance staff, and conversations. You are reducing the risk of accidental exposure (e.g., shoulder-surfing), opportunistic theft (e.g., laptop left unlocked), and intentional misuse (e.g., photos of sensitive screens). 1
Who it applies to
Entity scope
This applies to any organization running an ISO 27001 ISMS, including service organizations, and it extends to internal teams and third parties who perform work inside your secure areas (contractors, cleaners, facilities vendors, ISP technicians, auditors). 2
Operational contexts where it matters most
Use this control wherever any of the following occur:
- Administrative access to production systems (ops rooms, NOC/SOC, DBA workstations in restricted zones). 1
- Concentration of sensitive assets (data centers, server rooms, network closets, backup tape storage). 1
- Sensitive paper or regulated records (HR files, legal case files, customer identity documents). 2
- Confidential conversations (executive areas, incident war rooms). 2
What you actually need to do (step-by-step)
Step 1: Build a “Secure Area Register”
Create a simple register (spreadsheet is fine) that becomes the source of truth.
Minimum fields to include
- Secure area name and location/boundary description
- Area owner (Facilities/Security/IT) and backup owner
- Information types handled (e.g., customer data, credentials, keys)
- Authorized roles (not individuals yet)
- Entry/exit controls in place (badge, key, mantrap, guard)
- Working rules that apply (reference to standard)
- Logging expectations (visitor log, badge report, CCTV retention reference)
- Exceptions and compensating controls (if any)
This register is the anchor for consistent audits and recurring evidence. 2
Step 2: Define “Working in Secure Areas” rules that are enforceable
Write a short standard (two to five pages) that sets non-negotiable behaviors. Make it specific enough that a manager can enforce it and an auditor can test it.
Core rule areas to cover
- Screen and workstation controls
- Lock screens when unattended.
- Position screens to reduce casual viewing; use privacy filters where needed.
- Paper and media handling
- No unattended sensitive printouts.
- Use secure bins for disposal; no “to shred later” piles.
- Restrict removable media; require approval and tracking if used.
- Device restrictions
- Rules for phones/cameras (prohibit photography; require stickers; define exceptions).
- Rules for personal devices in data centers or records rooms.
- Visitor and third-party working rules
- Escort requirements, badge visibility, prohibited areas, sign-in/out.
- Maintenance work must be scheduled, authorized, and supervised for sensitive zones.
- Conversations and audio
- No speakerphone for sensitive calls in shared secure areas unless authorized.
- Whiteboard/photo rules (erase after meetings; no photos).
- End-of-day checks
- Clear desk / clear screen expectations for secure rooms.
- “Last person out” checklist for certain rooms (where appropriate).
Tie each rule to who owns it (Facilities, Security, IT, team managers). 1
Step 3: Align with related Annex A controls so it works in real life
Annex A 7.6 rarely stands alone. Cross-reference your standard and evidence with:
- Physical entry controls (who can enter). 1
- Visitor management (how visitors are logged and escorted). 2
- Asset management and acceptable use (devices/media expectations). 2
- HR/training and awareness (people know the rules). 2
This reduces audit friction because you can show a coherent set of controls instead of isolated documents. 2
Step 4: Implement operational routines (where audits are won)
Set a cadence of checks and recordkeeping that proves the control operates.
Operational routines to establish
- Access review routine: Area owner reviews authorized individuals/roles and removes stale access.
- Visitor/contractor routine: Reception/security validates ID, logs visits, and enforces escorting.
- Workspace inspection routine: Managers or security perform walkthroughs for clear desk/screen compliance.
- Maintenance routine: Facilities/IT records who performed work, when, and under whose supervision.
- Incident routine: Define what happens if someone violates secure-area rules (document, retrain, escalate).
Keep the routines lightweight, but consistent. In practice, “spot checks with documented outcomes” are easier to sustain than complex checklists that no one completes. 2
Step 5: Map requirements to evidence capture (make it repeatable)
Your goal is a predictable evidence packet per secure area.
A simple approach:
- For each secure area, create an “Evidence” folder with subfolders: Access, Visitors, Inspections, Training, Exceptions.
- Require area owners to drop artifacts in monthly or quarterly (your choice) and review for completeness.
- Track open issues in a corrective action log.
Daydream (or any GRC workflow tool) fits here by turning “evidence due” into assigned tasks with reminders, review, and an audit-ready trail, so you are not chasing screenshots before the audit. 2
Required evidence and artifacts to retain
Retain artifacts that prove both design (rules exist) and operation (rules are followed).
Design evidence
- Secure Area Register (current version + change history)
- Working in Secure Areas standard/procedure
- Secure area signage standards (what signs are posted and where)
- Role definitions for area owners and escorts
- Exception process (template + approval workflow)
Operating evidence
- Badge/access lists and access review outcomes
- Visitor logs (including third parties) and escort attestations where required
- Inspection/walkthrough records and remediation notes
- Training completion records for staff with secure-area access
- Maintenance/service tickets showing authorized, supervised work
- Exception approvals and compensating controls evidence
Audit tip: include at least one example per secure area, not just one “model” room. Auditors test consistency across locations. 2
Common exam/audit questions and hangups
Questions you should be ready to answer
- “Show me your secure areas. How do you decide what qualifies?” 1
- “Who is allowed in this room, and who approved that access?” 2
- “What rules apply once someone is inside?” 1
- “How do you control third parties working here?” 2
- “Show evidence this is checked and enforced.” 2
Typical hangups
- Secure area definition drift: Facilities thinks it is only the data center; Security thinks it includes SOC; Legal thinks it includes records storage. Fix by using one register with accountable owners. 2
- Evidence gaps: Teams do the right thing but cannot prove it. Fix by baking evidence capture into routine operations. 2
Frequent implementation mistakes and how to avoid them
| Mistake | Why it fails | Avoid it by doing this |
|---|---|---|
| Only documenting door controls | 7.6 is about work behaviors inside the space | Publish a working-in-secure-areas standard with testable rules. 1 |
| Treating visitors as “Facilities’ problem” | Third parties create real exposure in secure zones | Require sign-in/out, visible badges, and escorts for defined rooms. 2 |
| No owner per secure area | Nobody fixes violations or stale access | Assign an area owner and backup; include in job responsibilities. 2 |
| Exceptions handled informally | Auditors treat informal exceptions as control failure | Use a written exception process with approvals and expiry. 2 |
| Training is generic | People cannot recall the room-specific rules | Add short, targeted training for secure-area users and escorts. 2 |
Enforcement context and risk implications
ISO 27001 is a certifiable standard, not a regulator, so “enforcement” typically shows up as audit nonconformities, customer assurance failures, or contractual findings rather than fines. The risk is practical: weak secure-area work practices can expose credentials, system consoles, sensitive printouts, and discussions that materially increase incident likelihood and impact. 2
A practical 30/60/90-day execution plan
Use this plan to operationalize quickly without betting everything on a long policy rewrite.
First 30 days (stabilize scope and ownership)
- Create the Secure Area Register and get sign-off on what is included. 2
- Assign an owner and backup for each secure area. 2
- Draft the Working in Secure Areas standard with a short set of enforceable rules. 1
- Add signage for the highest-risk areas (e.g., “Authorized personnel only,” “No photography”). 2
Days 31–60 (implement routines and evidence)
- Implement visitor logging and escort expectations for each secure area. 2
- Start inspections/walkthroughs and track findings to closure. 2
- Create an exception template and require expiry dates and compensating controls. 2
- Train secure-area users and escorts on the room-specific rules. 2
Days 61–90 (prove operation and harden weak points)
- Run an access review for each secure area and remove unnecessary access. 2
- Collect an evidence packet per secure area (access, visitors, inspections, training, exceptions). 2
- Perform an internal readiness review: interview staff, test visitor handling, and spot-check desks/screens. 2
- If you use Daydream, convert each evidence item into a recurring task with review/approval so collection becomes routine rather than a pre-audit scramble. 2
Frequently Asked Questions
What counts as a “secure area” for Annex A 7.6?
Any space where sensitive information is processed, stored, or discussed, or where administrative access to critical systems occurs. Define it in a Secure Area Register with boundaries and an accountable owner. 2
Do we need different rules for different secure areas?
Often yes. Keep one baseline standard, then add room-specific addenda for higher-risk spaces like data centers or records storage. Auditors expect the rules to match the real risks of the area. 1
How do we handle third parties like cleaners or HVAC technicians?
Treat them as visitors or authorized contractors with documented approval, sign-in/out, visible identification, and escorting where required. Keep logs and work tickets that show supervision for sensitive areas. 2
What evidence is usually missing during ISO audits for 7.6?
Teams often lack proof of ongoing operation: access reviews, visitor logs, inspection records, and documented exceptions. Fix it by making evidence capture part of a routine owned by each secure-area owner. 2
We have badge access controls. Isn’t that enough?
Badge controls address entry, but 7.6 also expects controlled working practices inside the area, such as screen handling, paper/media controls, and visitor conduct. Document rules and show they are enforced with inspections and logs. 1
How do we operationalize this across many offices without drowning in admin?
Standardize the register format, define a small set of mandatory artifacts, and assign local area owners. A workflow tool like Daydream can track recurring evidence requests and approvals per site so you keep consistency without chasing emails. 2
Footnotes
Frequently Asked Questions
What counts as a “secure area” for Annex A 7.6?
Any space where sensitive information is processed, stored, or discussed, or where administrative access to critical systems occurs. Define it in a Secure Area Register with boundaries and an accountable owner. (Source: ISO/IEC 27001 overview)
Do we need different rules for different secure areas?
Often yes. Keep one baseline standard, then add room-specific addenda for higher-risk spaces like data centers or records storage. Auditors expect the rules to match the real risks of the area. (Source: ISMS.online Annex A control index)
How do we handle third parties like cleaners or HVAC technicians?
Treat them as visitors or authorized contractors with documented approval, sign-in/out, visible identification, and escorting where required. Keep logs and work tickets that show supervision for sensitive areas. (Source: ISO/IEC 27001 overview)
What evidence is usually missing during ISO audits for 7.6?
Teams often lack proof of ongoing operation: access reviews, visitor logs, inspection records, and documented exceptions. Fix it by making evidence capture part of a routine owned by each secure-area owner. (Source: ISO/IEC 27001 overview)
We have badge access controls. Isn’t that enough?
Badge controls address entry, but 7.6 also expects controlled working practices inside the area, such as screen handling, paper/media controls, and visitor conduct. Document rules and show they are enforced with inspections and logs. (Source: ISMS.online Annex A control index)
How do we operationalize this across many offices without drowning in admin?
Standardize the register format, define a small set of mandatory artifacts, and assign local area owners. A workflow tool like Daydream can track recurring evidence requests and approvals per site so you keep consistency without chasing emails. (Source: ISO/IEC 27001 overview)
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream