Courseiva
Scope OF System →hardMultiple Choice

CGRC Practice Question: Your organization is transitioning to a 'System of Systems' architecture

Your organization is transitioning to a 'System of Systems' architecture. When defining the boundary for one sub-system, what is the best practice to avoid scope creep?

⚠ Common exam trap

CGRC often tests the tendency to over-include (entire enterprise) or under-include (only database) when defining boundaries, tempting candidates to choose extremes rather than the balanced, service-and-data-flow-based approach.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Define the boundary based on the specific services and data flows owned by the sub-system.

When defining the boundary for a sub-system within a System of Systems architecture, the best practice is to define it based on the specific services and data flows owned by that sub-system. This approach ensures a clear, manageable scope that aligns with the sub-system's responsibilities and avoids including unrelated components that would cause scope creep. It also facilitates independent authorization and risk management for each sub-system.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Define the boundary based on the specific services and data flows owned by the sub-system.

    Why this is correct

    Anchoring the boundary to services and data flows the sub-system actually owns creates an explicit, verifiable interface contract. This constrains scope to defined responsibilities, preventing adjacent capabilities from being absorbed and satisfying the System of Systems need to avoid scope creep.

  • ✗

    Include only the database tier.

    Why it's wrong here

    Restricting the boundary to the database tier omits the interfaces and services the subsystem depends on, leaving integration points ungoverned. Database-only scoping suits a standalone data store, not a subsystem within a system of systems.

  • ✗

    Include the entire enterprise infrastructure to be safe.

    Why it's wrong here

    Including the entire enterprise infrastructure dissolves the sub-system boundary, so the authorisation boundary cannot be scoped, documented or assessed against a defined set of controls. It is tempting because enterprise-wide boundaries suit single-system accreditations, where one authorisation package covers all interconnected components under one security categorisation.

  • ✗

    Include all internal network segments regardless of use.

    Why it's wrong here

    Including every internal network segment regardless of use expands the boundary beyond the sub-system's actual function, so interfaces and dependencies multiply and scope creep follows. Segmentation by function defines the boundary. This option would suit mapping an entire enterprise enclave for network inventory, not scoping a single System of Systems sub-system.

About these practice questions

Courseiva writes every CGRC question from scratch — 341 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

You might also like

Similar CGRC questions

Written and reviewed by Johnson Ajibi, MSc IT Security

Security Systems Architect · founder of Courseiva

Last reviewed September 2026 · checked against the official (ISC)² exam blueprint

This CGRC practice question is part of Courseiva's free (ISC)² certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CGRC exam.