# Cloud Requirements Scoping and Design Principles

> Chapter 2 of the Courseiva ISC2-CCSP curriculum — https://courseiva.com/learn/isc2-ccsp/cloud-requirements-scoping-and-design

**Official objective:** 1.2 — Describe cloud requirements scoping, design, and architecture principles

## Introduction

How do you build a cloud system that is secure, fast, and doesn't cost a fortune — before writing a single line of code? The answer lies in two critical steps: requirements scoping and design principles. For the CCSP exam, understanding how to define what a cloud system must do (scoping) and how to architect it securely from day one (design principles) is the foundation of everything else you will learn. Get this wrong, and every security control you add later will be a patch on a leaky boat.

## The House Renovation Architect Analogy

Why does your house renovation keep going over budget and taking twice as long as promised? Because you started buying tiles before you checked if the walls could support them. That is exactly what happens in cloud projects without proper scoping and design.

Imagine you decide to renovate your kitchen. You don't just call a contractor and say 'make it nice'. First, you figure out your requirements: do you need space for six people to eat breakfast? Is your partner allergic to certain materials? Do you have a budget of £5,000 or £50,000? That is scoping — defining exactly what the project must achieve, what it must cost, and what rules (like building codes) it must follow. Next, you hire an architect who draws detailed plans. They decide where the oven goes, how the plumbing runs, and where electrical outlets sit. That is design — creating a blueprint that meets your requirements. Finally, the contractor builds from that blueprint. If you change the blueprint mid-build (say, decide to move a wall after the pipes are laid), it costs a fortune. In cloud computing, 'requirements scoping' means understanding what security rules, performance needs, and legal regulations your project must satisfy. 'Design principles' are the architectural rules (like 'defence in depth' and 'least privilege') that ensure your cloud system is secure, scalable, and cost-effective — exactly like building codes and good architecture for your house. If you skip either step, your cloud project, like a bad renovation, will fail spectacularly.

## Core explanation

Let us strip away the jargon. Cloud Requirements Scoping is the process of figuring out, before you build anything, exactly what the cloud system needs to achieve, who will use it, what data it will handle, and what laws apply to it. Think of it as the 'discovery phase'. If you miss a requirement here, you will have to rebuild whole parts of the system later, which is expensive and risky.

Design Principles are the fundamental rules that guide how you build the system to meet those requirements securely. They are like the 'laws of physics' for cloud architecture. The CCSP exam focuses on a specific set of these principles, each of which solves a common problem.

The most important design principles you must know for the exam are:

- Defence in depth: Do not rely on a single security control (like a firewall). Layer multiple controls so that if one fails, another catches the threat. Think of it like a castle with a moat, a drawbridge, walls, and guards inside.
- Least privilege: Give every user, application, or system the absolute minimum permissions it needs to do its job — nothing more. If a user only needs to read files, do not give them write or delete permissions. This limits the damage if their account is compromised.
- Separation of duties: Split critical tasks among multiple people so no single person can misuse the system. For example, the person who requests a change to a firewall rule should not be the same person who approves and implements that change.
- Secure defaults: Configure every cloud resource (like a database or a storage bucket) to be secure by default (e.g., private, not accessible from the internet). The user must deliberately choose to make it less secure.
- Fail securely: When a system fails (a server crashes, a network goes down), it should fail into a secure state. For example, a firewall that crashes should block all traffic, not allow all traffic through.
- Regular testing and auditing: Continuously test your security controls and audit your logs to find misconfigurations and attacks. You cannot assume your system is secure; you must verify it.

Why does scoping matter so much? Imagine a healthcare company that wants to store patient records in the cloud. If they skip scoping, they might pick the cheapest cloud storage option. But patient health data is regulated by laws like HIPAA (in the US) or GDPR (in Europe). Those laws require specific security measures (encryption, access controls, audit logs) and specify where data can be stored (e.g., must stay within the UK or EU). If the company had scoped their requirements first, they would have known these rules and chosen a compliant storage option. By skipping scoping, they break the law, face huge fines, and lose customer trust.

Scoping typically involves gathering requirements from stakeholders (business owners, legal teams, security teams, end users). You categorise these into functional requirements (what the system does — 'users must be able to upload a photo') and non-functional requirements (how the system behaves — 'uploads must complete within 2 seconds', 'the system must be available 99.99% of the time'). Security requirements (like 'all data must be encrypted at rest') are a subset of non-functional requirements.

Design principles then translate these requirements into an architecture. For example, if a requirement is 'the service must be available 99.99% of the time' (non-functional), the design principle of 'redundancy' (not in the list above but closely related) tells you to run the service in multiple data centres (Availability Zones) so that if one fails, the other takes over without interruption.

In the old on-premises world, you bought servers and built everything in your own building. Scoping and design were still important, but mistakes were slower to become catastrophes because you had months to build. In the cloud, you can provision a server in minutes. That speed is wonderful, but it means a misconfiguration (like making a storage bucket public) can expose data to the entire internet within seconds. Scoping and design principles are your safeguard against the speed of cloud deployment turning into an instant security disaster.

## Real-world context

A mid-sized UK company, 'MediRecords Ltd', wants to move its patient appointment system from their own server room to the cloud. The IT lead, Sarah, has a budget of £50,000 and a deadline of 6 months. Here is what she actually does.

First, Sarah runs a scoping workshop. She sits down with:
- The CEO, who says: 'We need the system to be available 24/7 — we cannot turn patients away.'
- The legal team, who says: 'Patient data is covered by UK GDPR. We need a Data Processing Agreement (DPA) with the cloud provider, and data must stay in the UK.'
- The finance team, who says: 'No surprise bills. We need a predictable monthly cost.'
- The clinicians, who say: 'When I click 'book', it must save in under 2 seconds.'

Sarah documents all these as requirements. She then writes a requirements document that includes:
- Availability: 99.99% uptime (non-functional)
- Regulation: UK GDPR compliance, data residency in UK (security/legal requirement)
- Performance: API response time < 2 seconds for 95% of requests (non-functional)
- Cost: predictable, with a cap of £4,000/month (business requirement)

Next, Sarah moves to design. She chooses a cloud provider (like AWS or Azure) and applies the design principles. She designs a 'defence in depth' architecture:
- Network layer: The appointment database sits in a private Virtual Private Cloud (VPC) segment with no direct internet access. Only the application servers, also in a private segment, can connect to the database.
- Identity layer: Clinicians log in using multi-factor authentication (MFA). Each clinician only sees their own clinic's appointments (least privilege).
- Application layer: The application server validates all inputs to prevent hacking attempts (e.g., SQL injection).
- Data layer: All patient data is encrypted at rest (when stored) and in transit (when moving between components).

She also applies separation of duties: Sarah's team can propose changes to firewall rules, but a separate security team (or automated tool) must approve and apply them. The finance team gets a read-only dashboard showing costs (least privilege — they do not need to change infrastructure).

Sarah then builds the system on paper, running it past the legal and security teams for review (a design review). Only after approval does she start provisioning cloud resources. During the build, the team tests each security control. For example, they try to access the database from the public internet — it should be blocked. They also run a cost simulation to ensure it stays within budget.

At the end of 6 months, the system goes live. Because Sarah scoped and designed properly, there are no late-stage surprises. The system is compliant, secure, and within budget. If Sarah had skipped scoping and just started building, she might have chosen a US-based cloud region (breaking data residency laws) or used a single server (meaning a failure would shut down the clinic). The difference between success and disaster was the upfront work of scoping and design.

## Exam focus

The CCSP exam loves to test your understanding of cloud requirements scoping and design principles in specific, often tricky ways. Do not assume you can memorise definitions alone — you need to apply them to scenarios.

Here are the exact traps and topics you will encounter:

- 'Which of the following is the FIRST step in designing a secure cloud system?' The correct answer is always 'requirements gathering and scoping'. Traps: 'Selecting a cloud provider' or 'choosing an encryption algorithm' are later steps. The exam tests that scoping comes before everything.

- 'A company wants to move a legacy application to the cloud with minimal changes. Which design principle is MOST relevant?' The correct answer is often 'least privilege' or 'defence in depth' depending on the scenario. Trap: the exam gives you a scenario about cost savings but expects 'secure defaults'. You must read the scenario's core problem (e.g., 'users have more access than needed' = least privilege).

- The exam will list the design principles and ask you to match them to a description. For example, 'Implementing multiple overlapping controls is an example of which principle?' Answer: defence in depth. Memorise the six core principles (defence in depth, least privilege, separation of duties, secure defaults, fail securely, regular testing) and their definitions.

- Scoping outputs: The exam tests that scoping produces a 'requirements document' and a 'risk assessment'. Do not confuse 'requirements document' with 'architectural diagram' (that comes later, in design).

- Data classification: A key part of scoping is identifying what data the system handles and classifying it (e.g., public, internal, confidential, restricted). The exam will ask: 'During scoping, which activity is critical for selecting appropriate security controls?' Answer: data classification. Trap: 'selecting encryption keys' is done after scoping, during implementation.

- Regulatory compliance: The exam frequently presents a scenario with a specific regulation (GDPR, HIPAA, PCI DSS) and asks which requirement must be included in the scoping phase. The correct answer is always something like 'data residency requirements' or 'data protection impact assessment'. Study the major regulations and what they mandate (e.g., GDPR requires a Data Protection Officer for certain organisations).

- Common exam traps:
  - 'All design principles apply equally to every project.' (False — you select principles based on the scoped requirements.)
  - 'Scoping is a one-time activity at the start.' (False — requirements can change, and scoping should be revisited if major changes occur.)
  - 'Design principles only apply to security.' (False — they apply to performance, availability, and cost as well. For example, 'redundancy' improves availability, not just security.)

- Key definitions to memorise exactly:
  - Requirements scoping: the process of defining and documenting the functional, non-functional, security, and regulatory requirements for a cloud system.
  - Design principle: a fundamental rule or guideline that informs the architecture of a cloud system to meet its requirements securely and efficiently.
  - Defence in depth: a layered security strategy that uses multiple independent controls to protect assets.
  - Least privilege: granting only the minimum permissions necessary to perform a function.
  - Separation of duties: dividing critical tasks among multiple individuals to prevent fraud or misuse.
  - Secure defaults: configuring a system with the most restrictive security settings as the starting point, requiring explicit action to relax them.
  - Fail securely: ensuring that when a system fails, it does so in a secure state (e.g., blocking access rather than allowing it).

The exam will also ask about 'stakeholders' who participate in scoping. The three main groups are business owners (sponsors), legal/compliance, and technical teams. A trap question might list only the technical team as stakeholders — that is wrong. Scoping requires input from all three.

## Step by step

1. **Identify Stakeholders** — List everyone who has a stake in the cloud project: business owners (who pay for it), legal/compliance officers (who ensure regulations are met), security team, and end users. Without their input, your requirements will be incomplete. This step is part of requirements scoping.
2. **Gather and Document Requirements** — Hold workshops or interviews with stakeholders to collect functional requirements (what the system must do), non-functional requirements (performance, availability, scalability), security requirements (encryption, access controls), and regulatory requirements (GDPR, HIPAA, data residency). Write them all in a requirements document. This is the core of scoping.
3. **Classify Data** — Identify what data the system will handle (customer PII, financial records, public information) and classify it into categories (e.g., public, internal, confidential, restricted). The classification level dictates which security controls you must apply. For example, 'confidential' data may require encryption and strict access logging. This is a sub-step of scoping.
4. **Select Design Principles** — Based on the documented requirements, choose which design principles to apply. For example, if the system handles sensitive data, 'defence in depth' and 'least privilege' are mandatory. If the system is critical for 24/7 operations, 'fail securely' and 'redundancy' (an implied principle) are key. This step bridges scoping and design.
5. **Create the Architecture Blueprint** — Translate the requirements and design principles into a technical architecture. Draw diagrams showing network segments, where data flows, how users authenticate, and where encryption is applied. Include specific cloud services (e.g., a private virtual network, an encrypted database, load balancers for availability). This is the design phase. Validate it with stakeholders before building.
6. **Perform a Design Review and Risk Assessment** — Before provisioning any cloud resources, review the architecture with the security and legal teams. Assess the risks of the design (e.g., 'If this network segment is misconfigured, data could leak') and decide how to mitigate them. Update the design if needed. This is a final check before implementation.

## Comparisons

### Requirements Scoping vs Design Principles

**Requirements Scoping:**
- Answers 'what needs to be achieved?' e.g., 'system must handle 1000 users per second'
- Output is a documented set of requirements and risk assessment
- Involves stakeholders from business, legal, and technical teams

**Design Principles:**
- Answers 'how should we build it to be secure?' e.g., 'use least privilege to limit access'
- Output is a set of architectural rules applied to the design blueprint
- Applied by architects and security engineers based on scoped requirements

### Least Privilege vs Separation of Duties

**Least Privilege:**
- Controls the level of access (e.g., read-only vs. admin)
- Applies to a single user or system: 'you get the minimum needed'
- Implemented via IAM policies or Role-Based Access Control (RBAC)

**Separation of Duties:**
- Controls the process of access (e.g., request must be approved by another)
- Applies to a workflow involving multiple people: 'two people must act'
- Implemented via approval workflows or ticketing systems

### Defence in Depth vs Secure Defaults

**Defence in Depth:**
- Uses multiple overlapping layers of security (e.g., firewall + encryption + MFA)
- Active strategy: you intentionally add layers
- Assumes that a single layer will eventually fail

**Secure Defaults:**
- Sets the initial configuration to the most restrictive state (e.g., private storage bucket)
- Passive strategy: you start secure and only open what is needed
- Assumes that a single misconfiguration can be catastrophic if defaults are permissive

### Functional Requirement vs Non-Functional Requirement

**Functional Requirement:**
- Describes a specific behaviour or feature (e.g., 'user can upload a profile picture')
- Directly testable by checking if the feature works
- Often expressed as 'the system shall...'
- Example: 'the system shall encrypt all data at rest using AES-256'

**Non-Functional Requirement:**
- Describes a quality attribute (e.g., 'the upload must complete in under 3 seconds')
- Tested by measuring performance, availability, or security
- Often expressed as 'the system must be...'
- Example: 'the system shall be available 99.99% of the time'

## Diagram

_This flowchart shows the step-by-step process from requirements scoping through selecting design principles to creating the architecture blueprint for a secure cloud system._

```mermaid
flowchart TD
    A[Start: Requirements Scoping] --> B[Identify Stakeholders]
    B --> C[Gather Requirements]
    C --> D[Classify Data]
    D --> E[Document Requirements & Risk Assessment]
    E --> F[Select Design Principles]
    F --> G[Defence in Depth]
    F --> H[Least Privilege]
    F --> I[Separation of Duties]
    F --> J[Secure Defaults]
    F --> K[Fail Securely]
    G --> L[Create Architecture Blueprint]
    H --> L
    I --> L
    J --> L
    K --> L
    L --> M[Design Review & Approval]
    M --> N[Build & Test]
```

## Common misconceptions

- **Misconception:** Scoping and design are only for very large cloud projects. For small projects, you can just start building and figure it out as you go. **Reality:** Scoping and design are essential for projects of any size. Even a small cloud app handling personal data must comply with GDPR. Skipping these steps for a small project can lead to even faster and costlier mistakes because small teams often have fewer checks and balances. (Beginners often underestimate the complexity of security and compliance, thinking 'it is just a small app'. They also confuse speed of deployment (which cloud enables) with lack of need for planning. The exam explicitly tests that scoping is a mandatory first step regardless of project size.)
- **Misconception:** Design principles are just theoretical ideas that do not translate into real technical controls. The exam just expects you to memorise their names. **Reality:** Each design principle maps directly to specific technical implementations. For example, 'least privilege' is implemented via Role-Based Access Control (RBAC) and Identity and Access Management (IAM) policies. 'Defence in depth' is implemented using network security groups (NSGs), firewalls, and encryption. The exam tests your ability to apply the principle to a scenario, not just name it. (Learners often treat frameworks as abstract theory because they lack hands-on cloud experience. The CCSP exam is designed for professionals with experience, so it expects practical application. Beginners must force themselves to connect each principle to a real-world control.)
- **Misconception:** If you follow secure defaults, you will never have a security breach. **Reality:** Secure defaults reduce the likelihood of misconfiguration-based breaches, but they do not eliminate all threats. You still need other layers (defence in depth) and continuous monitoring. A breach can still occur through compromised credentials or application vulnerabilities. (Beginners see 'default' and assume 'automatic protection'. They forget that defaults only cover the initial state and that attackers evolve. The exam warns against placing too much trust in any single control.)
- **Misconception:** Separation of duties and least privilege mean the same thing. They both restrict what people can do. **Reality:** They are related but distinct. Least privilege limits the level of access a single person has (e.g., read-only vs. write). Separation of duties divides a process into steps performed by different people (e.g., request vs. approve). A person given 'read-only' access has least privilege applied, but separation of duties would also ensure they cannot approve another person's request to write. Both are needed. (The terms sound similar and are often taught together, so learners conflate them. The exam sets trap questions that use one term to describe the other, expecting you to spot the difference.)
- **Misconception:** Scoping is only about technical requirements like speed and storage capacity. Legal and business requirements are not part of cloud scoping. **Reality:** Scoping includes functional (what the system does), non-functional (how it performs), security (encryption, access control), and legal/regulatory requirements (GDPR, HIPAA, data residency). Ignoring legal requirements is a common reason cloud projects fail or result in fines. (Many beginners come from purely technical backgrounds and see 'cloud' as an IT problem. They forget that cloud services involve contracts, data sovereignty, and compliance. The exam emphasises that you must involve legal teams in scoping.)

## Key takeaways

- Requirements scoping must occur before any cloud resource is provisioned, and it must involve business, legal, and technical stakeholders.
- The six core design principles for cloud security are defence in depth, least privilege, separation of duties, secure defaults, fail securely, and regular testing/auditing.
- Data classification during scoping determines which security controls (e.g., encryption level) you will apply to each type of data.
- A single design principle, like defence in depth, is implemented using multiple overlapping technical controls (firewalls, encryption, access controls).
- Non-functional requirements (like availability and response time) are just as critical to scoping as functional requirements and directly influence design decisions.
- The output of scoping is a documented set of requirements and a risk assessment; the output of design is an architecture diagram and security blueprint.
- Cloud speed means misconfigurations can expose data globally in minutes, making proper scoping and design far more urgent than in on-premises environments.
- Separation of duties is not the same as least privilege; least privilege controls level of access, separation of duties controls process of access approval.
- Fail securely means a system in a failed state (e.g., crashed firewall) should deny all traffic, not allow it.
- Secure defaults mean the cloud provider's default configuration should be the most restrictive, and the customer must explicitly choose to open access.

## FAQ

**What is the difference between requirements scoping and design principles in simple terms?**

Requirements scoping is the process of asking 'what do we need?' and writing it down (e.g., 'the system must be available 99.99% of the time and handle medical data'). Design principles are the rules you follow to build it securely (e.g., 'we will use defence in depth and least privilege'). Scoping defines the goals; design principles guide how to achieve them.

**What does 'defence in depth' mean for cloud security?**

Defence in depth means not relying on a single security mechanism. For example, instead of just a password, you use a password plus multi-factor authentication plus a network firewall plus encrypted data. If one layer fails (e.g., someone guesses the password), the other layers (MFA, firewall) still block the attacker.

**When should I use 'least privilege' vs 'separation of duties'?**

You use least privilege to limit what a single person or system can do (e.g., a user can only read their own files). You use separation of duties to ensure no single person can perform a critical action alone (e.g., one person requests a firewall change, a different person approves it). Both should be used together.

**Do I need to do scoping if I am just moving a simple app to the cloud?**

Yes, absolutely. Even a simple app may handle personal data (like email addresses) that falls under GDPR or other regulations. Skipping scoping can lead to storing data in the wrong country (breaking data residency laws) or using the wrong encryption, exposing you to fines. Scoping is always the first step.

**What is a concrete example of a 'secure default' in cloud?**

A cloud storage bucket (like Amazon S3 or Azure Blob Storage) that is 'private' by default — meaning only authorised users within your organisation can access it. If you want to make it public (accessible to anyone on the internet), you must deliberately change a setting. The default state is secure.

**How does data classification affect design?**

If you classify data as 'confidential', your design must include encryption at rest and in transit, stricter access controls (e.g., least privilege for fewer users), and audit logging. If data is 'public', you may only need basic web security. Classification determines which design principles and controls are mandatory.

## Check your understanding

1. **What is the first step in designing a secure cloud system according to the CCSP objectives?**

   Answer: The first step is requirements scoping, which involves gathering and documenting all functional, non-functional, security, and regulatory requirements from stakeholders.

2. **A cloud architect configures a storage bucket to be private by default and requires a deliberate action to make it public. Which design principle is being applied?**

   Answer: Secure defaults, because the system starts in the most restrictive state and the user must explicitly choose to relax security.

3. **A company's system requires that one person submits a firewall change request and a different person approves and implements it. Which design principle does this enforce?**

   Answer: Separation of duties, because it splits the critical action of changing a firewall rule between two individuals to prevent misuse.

4. **During requirements scoping, a team identifies that their cloud system will handle customer medical records. What critical activity must they perform next?**

   Answer: Data classification, to determine the sensitivity of the data (e.g., confidential) and which regulatory requirements (like GDPR or HIPAA) and security controls apply.

5. **An organisation designs a cloud system with a firewall, encryption at rest, and multi-factor authentication. Which design principle are they primarily implementing?**

   Answer: Defence in depth, because they are using multiple overlapping security layers so that if one fails, another provides protection.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isc2-ccsp/cloud-requirements-scoping-and-design