ISO 27001 Clause 4: Understanding the Context of the Organization

The scope statement that cost Meridian Health $340,000

Priya Nakamura had been Meridian Health Analytics' first-ever Information Security Manager for exactly four months when the Stage 2 auditor asked her a question she couldn't answer cleanly: "Your scope statement says 'the ISMS covers the software development and hosting operations of Meridian Health Analytics.' Does that include the claims-processing subsidiary in Ohio?"

It didn't. Or rather, it was supposed to, but nobody had actually written that down. Meridian had acquired Clearpoint Claims Services eighteen months earlier, and Clearpoint's servers now sat in the same data center rack, on the same VLAN, processing the same patient records, as the systems Priya's ISMS was supposed to protect. The original scope document — inherited from a consultant who'd left the company a year before Priya arrived — had never been updated. Nobody in leadership had asked whether the merger changed what needed protecting.

The auditor didn't fail the audit outright. Instead, he raised a major nonconformity against Clause 4.3, because the documented scope didn't reflect the organization's actual boundaries, interfaces, and dependencies. Meridian had to pause the certification cycle, spend six weeks re-running its context analysis and interested-parties review, redraw the scope to explicitly include or formally exclude Clearpoint with a documented justification, and rebuild parts of its risk treatment plan and Statement of Applicability to match. By the time they re-submitted, they'd burned an extra $340,000 in consulting fees, delayed a customer contract that was contingent on certification, and spent a very uncomfortable board meeting explaining why "the easy clause" had derailed the whole program.

Here's the thing that still bothers me, fifteen-plus years and 200-odd ISO 27001 engagements into this career: Clause 4 is short. It's maybe a page and a half in the standard. Teams routinely treat it as throat-clearing before the "real work" of risk assessment and controls. And it is, without question, the single most common source of expensive rework I see in this framework. Get Clause 4 wrong, and every downstream artifact — your risk register, your Statement of Applicability, your internal audit plan, your certificate itself — inherits the flaw. Get it right, and the rest of the standard becomes dramatically easier to implement, because you're no longer treating a moving, undefined target.

This article is the walkthrough I wish I'd had before my first dozen scope statements went sideways.

Who this is for, and what you'll walk away with

This is for the ISMS manager, compliance lead, virtual CISO, or founder who has been handed responsibility for Clause 4 — whether you're building your ISMS from scratch or defending an existing scope statement against an upcoming audit. You'll walk away with a repeatable method for identifying external and internal issues under 4.1, a template-ready approach to interested-parties analysis under 4.2, a decision framework for drawing (and documenting) scope boundaries under 4.3, and a clear picture of what "establishing the ISMS" under 4.4 actually requires in practice. Every table in this piece is meant to be copied, adapted, and put into your own management system documentation — not admired and forgotten.

If you're newer to the standard generally, it's worth first grounding yourself in what ISO 27001 actually is and how the ISMS fits together before diving into Clause 4 specifics, since context-setting only makes sense once you understand what the management system is trying to achieve.

Why Clause 4 sits where it does

ISO 27001 isn't a standalone document — it's built on the "Annex SL" high-level structure that every modern ISO management system standard shares (ISO 9001 for quality, ISO 14001 for environment, ISO 22301 for business continuity, and so on). That's deliberate. It means an organization running multiple management systems can share a common backbone: context, leadership, planning, support, operation, performance evaluation, and improvement — Clauses 4 through 10. If you've ever wondered why ISO 27001's clause numbering looks oddly similar to other management standards you've encountered, that's why; it's explained in more depth in our comparison of ISO 27001 and ISO 27002, since 27002 provides the control guidance while 27001 provides this shared management system skeleton.

Clause 4 is the foundation course of that structure. It answers three questions an auditor will always ask, in some form, before anything else: What is this organization, really, and what pressures shape its security needs? Who cares about this organization's information security, and what do they actually require? And exactly what — which systems, sites, people, processes, and data — is inside the fence versus outside it? Everything in Clause 5's leadership commitments, Clause 6's risk assessment and objectives, and Clause 8's operational risk treatment is scoped by the boundary Clause 4 draws. If that boundary is wrong, everything built on top of it is wrong too — just less visibly, until an auditor or an incident finds the gap.

The four sub-clauses at a glance

Before we go deep on each one, here's the map. I hand this table to nearly every client in week one, because it's the single clearest way to show a skeptical executive why "the context clause" isn't bureaucratic filler.

Notice the dependency chain: 4.3 explicitly draws on the outputs of 4.1 and 4.2. You cannot competently scope an ISMS without first doing the context and interested-party work — which is exactly the step Meridian Health skipped.

4.1 Understanding the organization and its context

Clause 4.1 asks you to determine the external and internal issues relevant to your organization's purpose and its ability to achieve the intended outcomes of the ISMS. That's deliberately broad language, and I've watched it produce two failure modes in equal measure: teams who write nothing more than "we operate in a competitive market" and call it done, and teams who produce a forty-page PESTLE analysis that nobody ever references again. Neither survives an audit conversation, because the auditor's actual question is: does this analysis meaningfully shape your risk assessment and your objectives? If it doesn't, it's decoration.

The practical method I use with clients is a structured brainstorm, split into external and internal categories, with a "so what" column that forces a connection to information security. An issue that has no plausible link to confidentiality, integrity, or availability of information doesn't belong in this analysis — this isn't a general strategic-planning exercise, it's a security-focused one.

External issues: what's happening around you

External issues are forces originating outside the organization's control — but that still shape what your ISMS needs to account for. A common shorthand is PESTLE (Political, Economic, Social, Technological, Legal, Environmental), though I'd add a seventh lens specific to security: the threat landscape itself.

That "so what" habit matters more than the taxonomy. I've sat through context workshops where a well-meaning team spent forty minutes debating whether "inflation" belongs on the list. It doesn't, unless you can draw a line from inflation to a security-relevant consequence — say, budget cuts forcing a hiring freeze on the security team. If you can't draw that line in one sentence, leave it off.

Internal issues: what's happening inside you

Internal issues are things within the organization's own control that nonetheless affect the ISMS — culture, structure, capability, and existing commitments.

"The context analysis is the only place in the whole standard where I get to ask a room full of executives, out loud, 'what actually keeps you up at night about this business?' If you skip it, you end up building a security program for a company that doesn't exist." — Daniel Osei, Director of Information Security, Camberly Logistics Group

I usually run this as a 90-minute workshop with a cross-functional group — not just IT. Legal knows regulatory pressure. Sales knows what prospects are demanding. Finance knows where budget is tight. HR knows where turnover risk sits. A context analysis written solely by the security team is, in my experience, the single most reliable predictor of a scope that misses something an auditor later finds.

Turning the analysis into documented information

The standard doesn't mandate a specific format for 4.1, but auditors expect to see something durable — not a memory of a workshop that happened once. I recommend a simple, living context register: issue, category (external/internal), description, security relevance, and a review date. Keep it under management review as a standing agenda item (which ties directly into the leadership commitments covered in Clause 5), because context shifts — a new regulation, a new competitor breach, a reorg — and an ISMS that was scoped against last year's context is quietly drifting out of relevance even if nobody's told the auditor yet.

4.2 Understanding the needs and expectations of interested parties

If 4.1 is about the environment, 4.2 is about the people and organizations who have a stake in your information security — and, critically, what they actually require of you. This is the sub-clause where the 2022 revision of the standard sharpened the wording in a way that matters practically: it's no longer enough to just list interested parties and their requirements. You must also determine which of those requirements you will actually address through the ISMS. That distinction — "requirements that exist" versus "requirements we've chosen to address" — gives you a legitimate, documented basis for saying no to some things, which is enormously useful when a customer's security questionnaire demands twelve controls that have nothing to do with your risk profile.

Building the interested parties register

An interested party is any person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity of the ISMS. That's a wide net, so most practitioners group parties into standard buckets: customers, regulators, employees, shareholders/owners, suppliers/vendors, insurers, and industry bodies. Here's a working example built from a composite of engagements I've run for mid-sized SaaS companies:

That last "no" row is exactly the kind of entry that earns you credibility with an auditor. It signals you didn't just paste every conceivable requirement into a register — you actually thought about which ones the information security management system is the right vehicle to address.

"The 2022 wording change on 4.2 was small on paper and huge in practice. It gave us permission to write down, formally, 'this requirement exists, and no, the ISMS is not the mechanism that satisfies it.' Before that, every security questionnaire item felt like something we had to bend the ISMS to cover." — Renata Ferreira, ISMS Manager, Solvane Payments

Where interested-party requirements actually come from

In practice, requirements surface from a handful of predictable sources, and I tell clients to walk through each one deliberately rather than relying on memory:

If your organization sits at the intersection of multiple frameworks — say, ISO 27001 alongside SOC 2 or the NIST Cybersecurity Framework — this is the moment to reconcile overlapping requirements rather than build parallel, redundant registers. That mapping exercise is worth doing properly, and it's covered in more depth in our comparison of ISO 27001 against NIST, SOC 2, and PCI DSS.

Case study: the healthtech startup that discovered HIPAA wasn't optional

A composite case I draw on often: a 45-person digital health startup — I'll call them Ferrowell Health — came to us wanting ISO 27001 certification purely because two enterprise customers had asked for it. During the 4.2 exercise, we asked the obvious question: who else has a stake here? It turned out Ferrowell's platform stored protected health information for U.S.-based covered entities, which meant HIPAA obligations existed whether or not anyone had written them down. Nobody on the founding team — two engineers and a product lead — had connected "we store health data" to "we have a specific federal compliance obligation with civil and criminal penalties attached."

Once that requirement was formally logged in the interested-parties register and marked as addressed through the ISMS, it changed the shape of the entire program: business associate agreements got drafted, a formal risk analysis aligned to HIPAA's Security Rule was added alongside the ISO 27001 risk assessment, and two additional Annex A controls around third-party agreements were pulled into scope earlier than planned. The certification body auditor later called it out as a strength — clear evidence the organization understood its regulatory context, not just its customer contracts. Ferrowell passed Stage 2 on the first attempt, and leadership credited the 4.2 exercise, not the technical controls, as the turning point in how seriously the team took the whole program. If your organization handles health data alongside general commercial customers, this kind of cross-framework awareness is worth building deliberately — a discipline explored further in guidance on HIPAA compliance requirements for organizations layering multiple obligations on top of one ISMS.

How 4.1, 4.2, and interfaces converge on scope

Before we get into the mechanics of 4.3, it's worth seeing the whole picture in one view. This is the diagram I sketch on a whiteboard in nearly every scoping workshop:

Notice that scope isn't the first thing you decide — it's the output of everything upstream. Organizations that write the scope statement before doing the context and interested-party work almost always have to redraw it later, usually after an auditor asks a question nobody can answer, exactly as happened to Meridian Health.

4.3 Determining the scope of the ISMS

This is the sub-clause that decides whether your certificate means something or means almost nothing. A scope statement that's drawn too narrowly — say, "the ISMS covers the production AWS environment" while ignoring the developers' laptops, the ticketing system holding customer PII, and the HR platform storing employee data — produces a certificate that impresses nobody who reads it carefully. A scope drawn too broadly, without the resourcing to back it, produces a program that's perpetually behind and an audit that surfaces nonconformities everywhere.

The standard requires you to consider three specific inputs when determining scope: the external and internal issues from 4.1, the requirements from interested parties identified in 4.2, and the interfaces and dependencies between activities performed by the organization and those performed by other organizations. That third input is the one teams miss most often, and it's exactly what tripped up Meridian Health — shared infrastructure, outsourced functions, and organizational boundaries that don't align neatly with a business unit chart.

The three legally required scope inputs

Drawing the boundary: scope in vs. scope out

The clearest way I know to force clarity is a simple in/out worksheet, reviewed line by line with both technical and business stakeholders. Below is a composite example from a mid-sized fintech client — the kind of detail an auditor genuinely wants to see, not a vague paragraph.

Common scope-definition mistakes I still see constantly

"I ask every client the same blunt question before I'll sign off on a scope statement: if I handed this to a stranger with zero context on your business, could they draw your network diagram from these words alone? If the answer is no, it's not specific enough yet." — Marcus Wexler, Lead Auditor and Founder, Ironbrook Assurance Partners

What "documented information" actually means for scope

The standard is explicit that the scope must be available as documented information — not a slide in an old kickoff deck, not tribal knowledge held by the ISMS manager. In practice, I recommend a short, standalone scope statement document (one to three pages) containing five elements: the organizational units and locations covered, the products/services covered, the technology/infrastructure covered, explicit exclusions with justification, and the interfaces/dependencies with other organizations. Here's a side-by-side of a scope statement that fails this test versus one that passes it.

That level of specificity feels like overkill the first time you write it. It isn't. It's the difference between an auditor spending ten minutes confirming your scope and an auditor spending three days finding the edges of it themselves — the latter rarely goes well for the client.

Interfaces and dependencies deserve their own workshop

I've started running interfaces-and-dependencies as a standalone 45-minute session, separate from the general scoping conversation, because it consistently surfaces things nobody thought to mention. Questions I ask directly: Do we share a network, data center, or IT team with a parent or sister company? Do we outsource any function — payroll, customer support, development — to a third party who touches in-scope data? Do we have joint ventures or reseller relationships where data flows across an organizational boundary? Is there a holding company that sets policy for us but sits legally outside our entity? Every "yes" answer needs either an inclusion with a defined boundary or an exclusion with a documented rationale. There is no acceptable third option of silence.

Case study: the SaaS scale-up that scoped smart and closed the deal three weeks faster

A B2B SaaS company I'll call Northlake Analytics came to their ISO 27001 project with 260 employees, four product lines, and a sales team under pressure from a $2.1M enterprise deal that was contractually contingent on certification. Their instinct, like most first-timers, was to scope the entire company — every department, every internal tool, every regional office — because "it seemed safer to include everything."

We ran the 4.1/4.2 exercise first and it changed the calculus immediately. The interested-parties analysis showed the actual driving requirement was customer assurance over the core analytics platform and its supporting data pipeline — not the internal expense-reporting tool, not the marketing CRM with no customer production data, not the two satellite sales offices with no system access beyond email. We drew the scope around the platform, its CI/CD pipeline, the cloud infrastructure, and the support function that touched customer data — a boundary that took about 40% of the company's headcount to bring fully into scope, rather than 100%.

The result: an 11-week implementation instead of the 20+ weeks their initial "scope everything" plan would have required, a Stage 2 audit with zero major nonconformities, and — because the scope statement explicitly and clearly matched what the enterprise customer's security team cared about — the deal closed three weeks faster than the sales team had forecast, because the customer's own security reviewer could validate the certificate's relevance in a single call instead of a drawn-out back-and-forth about what was actually covered.

"We almost certified our expense report tool. In hindsight that sounds absurd, but when you're staring at the whole company and someone says 'just include everything to be safe,' it feels responsible. It's the opposite of responsible — it just dilutes your attention." — Aisha Thornbury, VP of Engineering, Northlake Analytics

4.4 Information security management system

Clause 4.4 is short but consequential: the organization must establish, implement, maintain, and continually improve an ISMS, including the processes needed and their interactions, in accordance with the requirements of the standard. Where 4.1 through 4.3 are about analysis, 4.4 is the pivot to action — it's the clause that says, in effect, "now go build the thing you just scoped." Everything from Clause 5 onward (leadership, planning, support, operation, performance evaluation, improvement) is how you satisfy 4.4 in detail; the sub-clause itself is more of a standing instruction than a discrete deliverable.

In practice, I treat 4.4 as the checkpoint where a client moves from "we've analyzed our context" to "we now have a named ISMS, with a defined owner, a defined set of interacting processes, and a governance rhythm." That means: a designated ISMS manager or equivalent role, a documented process map showing how risk assessment, incident management, access control, supplier management, and internal audit connect to one another, and a management review cadence that keeps the whole system alive rather than static. If you're looking for the deeper mechanics of resourcing, competence, and awareness that make 4.4 sustainable day to day, that's the territory covered in Clause 7 on support — worth reading immediately after this one, since establishing the ISMS and resourcing it are two sides of the same coin.

The process interaction map auditors want to see

A frequent 4.4-adjacent finding I raise in gap assessments: organizations can describe individual controls in isolation but can't explain how the processes interact. Auditors test this directly — ask how a vulnerability finding flows into the risk register, and if the answer is a shrug, that's a system that exists on paper but not in practice.

How Clause 4 drives the Statement of Applicability

It's worth being explicit about why getting Clause 4 right saves so much pain later. Your documented scope under 4.3, combined with the risk assessment conducted under Clause 6, determines which of the 93 controls across Annex A's four themes — organizational (5.1–5.37, 37 controls), people (6.1–6.8, 8 controls), physical (7.1–7.14, 14 controls), and technological (8.1–8.34, 34 controls) — are actually applicable to your organization. The Statement of Applicability is, in effect, a control-by-control reflection of the boundary you drew in 4.3 and the requirements you logged in 4.2. If your scope statement says a subsidiary is excluded, but your SoA lists controls that clearly apply to that subsidiary's infrastructure, an auditor will catch the inconsistency immediately — it's one of the fastest ways to expose a scope that was drawn carelessly.

If you haven't built your SoA yet, our Statement of Applicability template is a practical starting point once your scope and risk assessment are locked, and pairing it with the Annex A controls at a glance reference makes the control-selection conversation with stakeholders much faster.

The Clause 4 documentation artifacts an auditor will actually ask for

Across 200-plus engagements, the evidence request list for Clause 4 has stayed remarkably consistent. Here's the checklist I hand new clients so nothing is assembled at the last minute.

If you're not sure which of these documents are strictly mandatory across the whole standard versus useful-but-optional, our ISO 27001 mandatory documents checklist lays out the full list clause by clause, and it's worth cross-referencing before your internal audit so nothing is missing on the day.

Reviewing context and scope: this isn't a one-time exercise

The single fastest way to turn a well-built Clause 4 foundation into a future nonconformity is to treat it as done after certification. Context shifts constantly — new products launch, companies get acquired, regulations change, key customers churn, cloud providers get replaced. I recommend a formal trigger-based review in addition to the standing management review cadence: any M&A activity, any new product line handling a new data type, any material change in hosting/infrastructure provider, and any significant new regulatory obligation should each trigger an ad hoc review of the context analysis, interested parties register, and scope statement — not wait for the annual cycle.

Case study: the manufacturer that used context analysis to justify a smaller (and cheaper) ISMS

Not every Clause 4 story is about scope creep gone wrong — sometimes the discipline saves money outright. A mid-sized industrial parts manufacturer, which I'll refer to as Corravale Industrial, initially assumed ISO 27001 certification would need to span its entire operational technology environment, including factory-floor equipment, because "it's all networked together." That assumption alone had generated a vendor quote north of $180,000 for OT-specific security tooling before we'd even started the formal engagement.

Running the 4.1 and 4.3 exercises properly showed something different: the customer and regulatory pressure driving the certification project was entirely about protecting design files, customer specifications, and order data held in the corporate IT environment — not about the factory-floor programmable logic controllers, which had no interested party requiring them in scope and no interface exposing them to the corporate network beyond a well-documented, already-segmented firewall boundary. We drew the scope around the corporate IT environment and clearly documented the OT network as an interface with a defined, controlled boundary rather than an included asset.

That single scoping decision, backed by a documented rationale an auditor could independently verify, avoided roughly $180,000 in unnecessary OT security tooling and cut the certification timeline by an estimated ten weeks, because the team wasn't retrofitting controls onto industrial equipment that had never needed them for this particular certification's purpose. The auditor's only follow-up question was whether the firewall segmentation was tested — which it was, and which took twenty minutes to demonstrate.

"Scoping isn't about shrinking your security posture to look good on paper. It's about being honest about where the actual risk to the information you're certifying lives. We didn't ignore the factory floor — we just didn't pretend our ISMS was the right tool to govern it." — Tomasz Wieczorek, Head of IT, Corravale Industrial

Getting the terminology right before you write anything down

Clause 4 leans on a handful of terms — "interested party," "requirement," "scope," "documented information" — that the standard defines precisely, and imprecise use of them is a quiet tell to an experienced auditor that a team is working from templates they don't fully understand. If any of this vocabulary feels unfamiliar, it's worth a detour through our ISO 27001 terminology and glossary before you draft your own context analysis, and if you want the bigger picture of how the ISMS as a whole fits together conceptually — not just clause by clause — our explainer on ISMS core concepts is the natural companion piece to this one. It's also worth revisiting common myths about ISO 27001 at this stage, since "the context clause is just paperwork" is one of the more damaging misconceptions I encounter, right alongside "certification means we're totally secure."

Practical tools worth building alongside your Clause 4 work

Two artifacts I wish had existed as ready-made templates the first several times I ran this exercise: a structured guide to actually defining ISMS scope step by step, and a dedicated interested-parties register template with pre-populated categories. Neither exists yet as a standalone piece on PentesterWorld, but they're natural companions to this article and worth building out separately — a practical guide to defining your ISMS scope, and a template-driven guide to building your interested parties register.

In the meantime, if you want to sanity-check where your organization actually stands before committing to a scope, our gap analysis tool is a fast way to identify which areas of the standard need the most attention, and our certification readiness checklist is worth running through once your scope and context documentation are in draft form, before you schedule Stage 1.

Why Clause 4 is a business opportunity, not just an audit hurdle

I opened this article with a story about $340,000 in avoidable rework. I want to close with the more optimistic version of the same lesson, because it's the one that actually gets executives to engage with Clause 4 rather than delegate it entirely and hope for the best.

A well-executed context analysis is genuinely useful business intelligence — most organizations have never systematically written down which regulations apply to them, which customer segments are demanding what proof of security, and where their real dependency risk sits with vendors and subsidiaries. That analysis doesn't just satisfy an auditor; it sharpens how sales talks to prospects, how legal negotiates contracts, and how the board thinks about risk appetite. A precisely drawn scope statement, similarly, isn't a defensive document — it's a sales asset that lets your team answer a security questionnaire in one paragraph instead of three weeks of back-and-forth, because you already know exactly what's covered and why. Every client I've watched treat Clause 4 as a strategic exercise rather than a compliance checkbox has gotten to certification faster, spent less money doing it, and ended up with a certificate that actually holds up when a skeptical enterprise customer's security team starts asking pointed questions.

If you're earlier in the journey and still building the business case internally, it's worth pairing this work with our breakdown of ISO 27001 certification benefits, business case, and ROI — Clause 4 is where that ROI case either gets built on solid ground or quietly undermined from day one.

Whether you're drafting your first context analysis this week or defending an existing scope statement ahead of a renewal audit, PentesterWorld's ISO 27001 resource library has the templates, checklists, and calculators to help you get it right the first time — start with the gap analysis tool to see where you stand, then work through the mandatory documents checklist to make sure your Clause 4 evidence is audit-ready before Stage 1.

Who should actually be in the room for Clause 4 work

One of the most consistent predictors of a weak context analysis is who wasn't invited to build it. I've seen entire context and interested-parties exercises completed by a single compliance analyst working alone from a template, and the resulting documents read exactly like that — technically present, substantively thin. A RACI breakdown helps clarify ownership before the first workshop, and I share a version of this with every client kicking off Clause 4 work.

Notice that "Accountable" sits with top management throughout, not the ISMS manager. That's not a formality — Clause 5 makes leadership commitment to the ISMS an explicit requirement, and a scope statement that top management didn't genuinely review and approve is a common weak point auditors probe by simply asking a senior executive to explain, in their own words, what the certificate covers.

Choosing an analysis method: PESTLE isn't the only option

PESTLE is the most common framework I reach for in 4.1 workshops, but it's not the only valid lens, and different organizational contexts benefit from different tools. I keep this comparison handy when a client asks "do we have to use PESTLE specifically" — the answer is no, the standard doesn't mandate a method, only an outcome.

Whichever method you choose, document it. An auditor doesn't need you to have used a specific named framework, but they do want to see that the process was structured and repeatable rather than an unminuted hallway conversation.

Clause 4 across the certification lifecycle, not just at Stage 1

A mistake I see even in organizations that nailed their initial certification: treating Clause 4 outputs as a one-time deliverable for the initial audit rather than a living part of the three-year certification cycle. Auditors test context and scope differently at each stage, and it's worth knowing what to expect.

Organizations that keep this cadence in mind rarely get blindsided by scope-related findings later — the ones that don't are exactly the Meridian Health story repeating itself in a slightly different shape.

Scoping scenarios that don't fit the simple template

Most Clause 4 guidance, including much of this article, assumes a relatively straightforward single-entity organization. In practice, a meaningful share of the engagements I run involve a structural wrinkle that complicates the standard advice. It's worth naming the most common ones explicitly, because pretending your organization is simpler than it is tends to be exactly where scope statements go wrong.

None of these scenarios change the underlying requirement — consider 4.1 issues, 4.2 requirements, and interfaces and dependencies — but each one changes what "the boundary" naturally looks like on the ground. I've found that naming the organizational shape explicitly, early in the scoping conversation, saves a lot of circular debate later about whether a particular system or site belongs inside the fence.