Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

What belongs inside the boundary of our SOC 2 report?

6 decision pointsThe pack behind this answer: SOC 2 Report Readiness

Add to board memo

The short answer

Recommendation
Name the one service, then test every system, function, environment and route to production in turn: a provider gets its own decision, anything that touches customer data or production is inside, and only a stated fact keeps a thing out.
Reasoning
The description and every control depend on the boundary, and the CPA firm examines what management says it is. An exclusion made to save effort is the commonest way a boundary fails, so every exclusion needs a reason that is a fact about the system. People who run production see the routes in that the writer misses.
Considerations
  • A provider is not part of the system merely because you pay it. It is a subservice organisation when it runs part of the system and its controls matter to the commitments.
  • Staff of providers who work under your direction, and contractors with production access, belong in the people section.
  • Do the boundary checklist twice: on the first draft, and again after the readiness walkthroughs, when you know more.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartWe must draw the boundary of the system for the SOC 2 reportStepName the one service customers rely on, as the contract names itStepWrite down the principal commitments the service keepsStepList every candidate: components, functions, environments, routes inDecisionIs the candidate run by another company?StepSend it to its own carve-out, inclusive or outside decisionDecisionDoes it handle this service's customer data or reach production?StepPut it inside, in the section for its kindDecisionIs there a fact about the system that keeps it out?StepWrite it outside, with the reasonDecisionIs any other candidate left to decide?StepDraw the diagram so it shows the five components and each providerDecisionDo all twelve boundary checks read Yes?StepClose each gap by describing the system or changing itDecisionHas someone who runs production read it against the real system?StepGo through it with the engineer who knows production bestOutcomeBoundary drawn: keep the reasons and re-scope when things change

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one. A code beside a source, such as RR-17, is the number of a rule in that pack document; the document lists its rules.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 17 steps.

  1. Start

    We must draw the boundary of the system for the SOC 2 report

    The report is about one system, not the whole company: the service, and the infrastructure, software, people, procedures and data that provide it. Management owns the description, and the boundary decides what every control and the whole report are about. Start from the service the customer buys, then explain every exclusion.

    In the pack

  2. Step

    Name the one service customers rely on, as the contract names it

    Use the name customers use, and the same name that appears in the contracts. The first boundary check asks for one named service as the subject of the report. The report is about one system, so settle the one service before anything else.

    In the pack

  3. Step

    Write down the principal commitments the service keeps

    List the principal commitments made in contracts, service levels and published policies, with where each is made and what the system must do to keep it. The description must agree with the contract language. Where they differ the contract wins, so fix the description or change the contract.

    In the pack

  4. Step

    List every candidate: components, functions, environments, routes in

    Take the five components in turn: infrastructure, software, people, procedures and data. Then list what a reader might think is inside: support, onboarding and billing, the environments from production to development, and every route to production, such as administration consoles, single sign-on, remote access, the deployment pipeline and support tools.

    In the pack

  5. Decision

    Is the candidate run by another company?

    A provider is not part of the system merely because you pay it. It is a subservice organisation when it runs part of the system and its controls matter to the commitments. Choose providers from your supplier register and give each its own decision.

    In the pack

  6. Step

    Send it to its own carve-out, inclusive or outside decision

    Decide separately for each provider, before the description is written: carve-out, inclusive, or outside the boundary with a reason. Each leaves you something to do afterwards. “Which service providers do we carve out of our SOC 2 report, and what do we tell customers?” takes that decision in full.

    In the pack

    See also

  7. Decision

    Does it handle this service's customer data or reach production?

    Every system that stores, processes or sends customer data for this service is inside the boundary, or is a provider in the table. Every route to production is inside or accounted for. If the part serves the same customers with the same data, it is inside. If you are not sure, answer yes.

    In the pack

  8. Step

    Put it inside, in the section for its kind

    Describe it under infrastructure, software, people, procedures or data, and show it on the diagram. A no on a system that holds customer data is solved by describing the system, or by changing it. Every person with production access appears in the people section, including contractors.

    In the pack

  9. Decision

    Is there a fact about the system that keeps it out?

    Each exclusion needs a reason that is a fact about the system, for example that a separate company runs it with no access to the system. The boundary follows the service the customer buys, not the budget. If you cannot state the fact, the candidate is inside.

    In the pack

  10. Step

    Write it outside, with the reason

    Name it in the boundary section, with the reason, and name any function a reader might think is inside but is not. In the pack's worked example the marketing website is outside because it holds no customer data. Check each period that the reason still holds.

    In the pack

  11. Decision

    Is any other candidate left to decide?

    Go round again until every candidate is inside, a provider with a method chosen, or outside with a reason. Customer-facing functions and each environment are each decided, never left blank.

    In the pack

  12. Step

    Draw the diagram so it shows the five components and each provider

    The diagram shows the five components and where each provider sits, and it agrees with the text. Someone other than the writer, such as the Head of Engineering, compares it line by line with the infrastructure, software and boundary text.

    In the pack

  13. Decision

    Do all twelve boundary checks read Yes?

    The checklist has twelve checks, each answered Yes, No or Unsure, with where the evidence is. Anything other than Yes is a gap to close before the description is finalised. Do the checklist twice: on the first draft, and again after the readiness walkthroughs.

    In the pack

  14. Step

    Close each gap by describing the system or changing it

    A boundary drawn to leave out the awkward part is not a boundary. Fix the text, the diagram or the system, then run the checks again.

    In the pack

  15. Decision

    Has someone who runs production read it against the real system?

    A first description written by one person alone is almost always wrong in places. The people who operate the system read it against how it really works, and someone outside the writing team checks it against the records, such as the asset inventory and the production access list.

    In the pack

  16. Step

    Go through it with the engineer who knows production best

    Sit with the engineer who knows production best and compare each line of the boundary with how the system really runs. Note what is missing or wrong, fix it, and run the checks again.

    In the pack

  17. Outcome

    Boundary drawn: keep the reasons and re-scope when things change

    Keep the reason for each exclusion with the description. Re-scope when the service, the boundary, a major provider or a customer commitment changes, and before each new period, and write down why the scope is what it is.

    In the pack

    See also

Practical checklist

  1. Name the one service as customers and contracts name it.
  2. List every candidate: components, customer-facing functions, environments and every route to production.
  3. Send each provider to its own carve-out, inclusive or outside decision.
  4. Put inside anything that handles customer data for the service or reaches production, unless a stated fact keeps it out.
  5. Draw the diagram and run the twelve boundary checks.
  6. Have someone who runs production read the draft against the real system.

Evidence to have ready

  • The boundary section with what is inside, what is outside and the reason for each exclusion.
  • The diagram, checked line by line against the text.
  • The completed boundary checklist, with where the evidence for each check is.
  • The record of who read the draft against production and when.

Assumptions

  • You have chosen the one service the report is about, and you know which customers rely on it.
  • You can get someone who runs production to read the draft, and you can see the customer contracts.
  • A list of your suppliers exists to pick providers from, such as a supplier register.

Not covered here