A compliance walkthrough for startups

Startup Compliance Atlas

A customer asks for SOC 2, or your product starts handling data with specific requirements. You need to understand what applies before deciding what to do. This guide explains the basics, helps you choose a route, and takes you through the work your team will need to maintain.

Start here / The shared foundation

Learn the basics, then choose your compliance path.

You do not need to know the audit vocabulary to begin. Work through these four steps, then follow the route your business needs. SOC 2 is one route. Your startup may also have other requirements to address.

  1. Step 01

    Understand what compliance means

    A customer asks who can access its data and wants records supporting your answer. That request gives your team a concrete job: understand the requirement, check what happens today, and show the result. Compliance is the work of meeting the requirements that apply to your business.

    A prospective customer sends a security questionnaire. Before buying software or booking an audit, ask what decision they need to make and what evidence they will accept. A completed questionnaire, a security test, and an independent audit report answer different questions.

    Try this with your team: Write down what prompted this work, who needs an answer, and when they need it.

    Next: work out what applies
  2. Step 02

    Work out what applies to your startup

    Start with your product, customers, and data. Requirements can come from laws, signed agreements, or a customer's purchasing process. Keep those sources separate so you know which are obligations, which are requests you can discuss, and who can resolve an unclear answer.

    Describe the service in ordinary language: what it does, whose information it uses, where that information goes, and which providers help you run it. Include support tools and staff access. This description becomes your scope: the part of the business your compliance work covers.

    Try this with your team: Make a list with the requirement, its source, the service it affects, the person checking it, and any deadline. Have a qualified adviser resolve questions about legal applicability.

    NIST's Small Business Quick-Start Guide (February 2024) recommends identifying legal, regulatory, and contractual cybersecurity requirements and assigning responsibility. It is voluntary guidance for organizing security work.

    Next: turn requirements into work
  3. Step 03

    Turn requirements into work people can do

    A requirement tells you what needs to be true. A policy states your company's rule. A control is the check or procedure that puts the rule into practice. Give each control an owner who can explain how it works and who takes over when they are away.

    Suppose your policy says departing employees lose access. The control is the process that tells someone about the departure, removes access from the relevant systems, and checks the result. Writing the policy does not remove an account.

    Try this with your team: Choose one requirement and write the actual steps, the owner, when the work happens, and how you will check the result. Compare those steps with what your team does today.

    Next: understand evidence and review
  4. Step 04

    Keep records that show what happened

    Evidence is the record supporting an answer. In the employee example, that could include the departure request, dated access-removal records, and the check that access was removed. Save records as the work happens so you can explain the result later.

    A compliance platform can organize tasks and collect records, but someone still needs to check whether they answer the question. Readiness means preparing the work for review. If your chosen route includes an independent assessment, the auditor or assessor evaluates it under the agreed scope. Other obligations require ongoing work without an audit report at the end.

    Try this with your team: Pick a completed task. Ask someone who did not do it to explain what happened using only the saved records. Note what is missing or unclear.

    Our article on reviewing compliance evidence explains why collecting a record and judging what it proves are separate jobs.

    Next: choose the route you need
Step 05 / Choose your route

Take the path that fits your requirements.

Start with the requirements you identified above. These routes serve different purposes, and you may need more than one. A SOC 2 report does not settle every legal or contractual question for your business.

Step 06 / Put it into practice

Build a plan your team can keep running.

Choose your industry and where you are today. Use the actions below to move from understanding the requirements to assigning work, saving records, and keeping up with changes. Return to this plan as your business grows.

What are you building?
Where are you today?

Next outcome / B2B software

A documented scope connects your obligations to the systems and data you actually use.

Do not buy an audit against a scope nobody has agreed on.

  • Collect customer security requirements and relevant contract commitments. Record who needs assurance and when.
  • Map your product, data, people, locations, and vendors. Include the systems your team uses to administer production.
  • Have the appropriate reviewer assess applicable obligations and document exclusions with their reasons.
Read this stage's chapter

Prepare: A scope statement, data-flow diagram, and requirements register.

B2B software: before you move ahead

Start with the service a customer wants reviewed, the data it handles, and the assurance they have requested. Identify the people who can confirm security requirements and assessment scope.

  • Ask which integrations and security reviews are required for a pilot.
  • Agree on data use, retention, support, and the limits of the pilot.
  • If a buyer requests SOC 2, clarify report scope and timing with an independent CPA. Readiness work is separate from the examination.

Scope references, checked September 14, 2026: AICPA: SOC services

B2B software / Apply the pathway

The work specific to your industry.

Use these checkpoints to refine the scope and control plan. Where a review is needed, identify the person who can complete it and the information they need from your team.

  1. 01Scope

    Identify which product the customer wants assurance about and which systems support it.

  2. 02Plan

    Map the requested assurance criteria to current controls and agree on assessment scope.

  3. 03Implement

    Test tenant boundaries, administrative access, recovery, and change procedures.

  4. 04Evidence

    Collect evidence for the scoped service and explain exceptions to the reviewer.

  5. 05Maintain

    Review changes in hosting, identity, integrations, and vendors against prior evidence.

Research / B2B software

Agree on the assurance you need

Checked September 14, 2026

AICPA describes SOC services as assurance offerings provided by CPAs to help users assess controls and outsourcing risks. AICPA: SOC suite of services.

Ask the customer what they need to review, then agree on the intended engagement and scope with the CPA firm. Keep preparation work and the independent conclusion separate in your plan.

Prepare for the review: The customer's request, proposed service boundary, and agreed assessment scope.

From Sythe Labs research

Confirm the assurance request before scoping the work.

A prospect asks for SOC 2 while you are still agreeing on a pilot. Get the request in writing and find out who will review your answer. The product team may be ready to start while procurement is waiting for a report, a security questionnaire, or an explanation of how you handle its data.

Record the requested document, the product and systems it must cover, the reviewer's name, and the decision date. Ask which work must be finished before the pilot can start.

How we sequence SOC 2 readiness ·

The field guide

Work through your current stage.

The chapter for your selected stage is open below. Each chapter names the work, a suggested owner, and a completion check. Examples describe hypothetical companies.

01Define what needs to be covered

A customer questionnaire, a contract, and a regulation can ask different things of the same startup. Begin with the actual request and the activity behind it. Record what data you receive, what you do with it, and which systems and vendors participate. This boundary determines which controls and records need attention. An industry label is a starting point for questions, not a finished assessment of your obligations.

Work to complete

  • Keep a requirements register with the source, applicability decision, owner, and review date. Separate legal duties from customer commitments and voluntary assurance goals.
  • Draw the data flow from collection through processing, storage, sharing, and deletion. Include support tools, backups, and administrative access.
  • Identify the product and environment a customer or assessor will review. Document exclusions and the reason for each.
  • Confirm unresolved applicability questions with the appropriate adviser. For a SOC engagement, agree on the intended scope with the CPA firm.
02Turn requirements into owned work

Once the scope is clear, compare each requirement with what happens today. A gap may be a missing control, a control that fails, or work that happens without a usable record. Those require different fixes. Give each item an owner and a completion check, then schedule the dependencies together. Put testing, fixes, and evidence review on the same plan so each person knows when their work is needed.

Work to complete

  • For each gap, record the current state, required change, affected systems, owner, and verification method.
  • Prioritize exposed access and other material risks while making time for controls that need operating records.
  • Separate implementation work, testing, internal review, and independent assessment in the schedule. Confirm availability rather than assuming it.
  • Agree on how exceptions are approved and revisited. Record the reason, responsible decision-maker, and any temporary measures.
03Put controls into operation

A control becomes real when someone can carry it out in your environment. Access removal needs a person who knows which accounts to disable. Incident response needs a contact who can act. Recovery needs a backup the team can restore. Write down those responsibilities, implement the supporting settings, and test the steps before relying on them in an assessment.

Work to complete

  • Review privileged access, use individual accounts and MFA, and check how new starters, role changes, and departures are handled.
  • Document change approval and rollback, vendor review, incident escalation, and data handling for the scoped service.
  • Restore a backup in a safe environment and record the outcome. Test the customer access boundaries and other risks identified in your assessment.
  • Assign findings to owners, retest fixes, and retain the result. Obtain approval for policies from the people responsible for following them.
04Review the evidence and prepare for assessment

Evidence should answer a specific question about a control. A settings screenshot can show a configuration; a dated review can show that someone checked access; a restore result can show what happened when recovery was attempted. Keep those distinctions visible. The reviewer needs to understand what each record establishes, the environment it covers, and what remains unverified.

Work to complete

  • Build an evidence index with the control, record location, date or period, scope, owner, and review status.
  • Compare the policy, system configuration, and operating record. Investigate contradictions before sending the package.
  • Record findings and exceptions accurately, including their status and the next verification step. Do not recreate historical records as though they existed earlier.
  • Confirm the assessor's requested format, access, and evidence window. Prepare the people who will explain the controls.
05Keep the program current

The work continues when the report is issued or the customer review is finished. People leave, vendors change, and product releases alter the data flow. Keep a record of those changes and identify which controls or prior answers they affect. A small recurring review that catches a change is more useful than rebuilding the entire evidence folder before the next deadline.

Work to complete

  • Schedule access, vendor, policy, recovery, and other reviews at the cadence established for your program. Assign a backup owner.
  • Review changes to the scoped service and determine whether controls, testing, or customer disclosures need updating.
  • Track incidents and findings through resolution, including verification and changes to procedures.
  • Check the evidence index before renewals or reassessment. Preserve records for the retention period established for the program.
Working templates

Download a brief and fill in the missing details.

Use these records to scope the program, track remediation, and prepare evidence for review. Replace the example answers with records from your own environment.

Compliance scope

Download compliance scope (.md)
  • Service and environment
  • Data and locations
  • People and vendors
  • Requirements and their sources
  • Exclusions and reasoning
  • Scope reviewer and review date
See a filled example

Hypothetical software startup. Replace these answers with your own evidence.

Service and environment
Hosted customer application and its production administration.
Data and locations
Customer account records, hosting region, and backup locations documented in the data flow.
People and vendors
Engineering administrators, cloud provider, and support system.
Requirements and their sources
Customer requests a SOC 2 report; confirm the scope and engagement with the CPA firm.
Exclusions and reasoning
Marketing website excluded from the proposed service boundary; reviewer must assess shared dependencies.
Scope reviewer and review date
Engineering and compliance leads review the draft before confirming scope.

Control remediation plan

Download control remediation plan (.md)
  • Requirement or control
  • Current gap and affected systems
  • Risk and interim measures
  • Responsible owner
  • Implementation and verification steps
  • Due date and closure evidence
See a filled example

Hypothetical software startup. Replace these answers with your own evidence.

Requirement or control
Production access review.
Current gap and affected systems
Former contractor remains in the administrator list.
Risk and interim measures
Review current access immediately and remove access no longer authorized.
Responsible owner
Engineering lead.
Implementation and verification steps
Review the full administrator population, record decisions, and verify removals.
Due date and closure evidence
Close after reviewed decisions and removal records are attached.

Evidence index

Download evidence index (.md)
  • Control and claim supported
  • Record location
  • Collection date or covered period
  • System and population covered
  • Reviewer and review result
  • Exceptions and next action
See a filled example

Hypothetical software startup. Replace these answers with your own evidence.

Control and claim supported
Review of production administrator access.
Record location
Restricted evidence folder containing the export and signed review.
Collection date or covered period
Record the actual export and review dates.
System and population covered
All administrator accounts in the scoped production environment.
Reviewer and review result
Compliance lead checks that every account has a decision.
Exceptions and next action
One removal awaits verification; keep the item open.

Recurring review record

Download recurring review record (.md)
  • Control or change being reviewed
  • Review owner and date
  • Population and records examined
  • Findings and decisions
  • Remediation owner and due date
  • Verification result and next review
See a filled example

Hypothetical software startup. Replace these answers with your own evidence.

Control or change being reviewed
New support vendor with access to customer records.
Review owner and date
Compliance lead, on the recorded review date.
Population and records examined
Data flow, vendor terms, access settings, and available assurance records.
Findings and decisions
Approve only the documented data use; resolve retention settings before rollout.
Remediation owner and due date
Support owner configures retention and provides evidence.
Verification result and next review
Reviewer verifies settings and records the next review date.
Your next action

Which compliance gap will you close next?

Choose one task from the guide, assign someone to resolve it, and agree on what they will bring back. Download your notes before leaving this page; they are not saved between visits.

Download my action plan (.md)

Compliance scope and assurance references

Use the framework owner's guidance to confirm the intended assessment. Our readiness article explains how to sequence the work before independent review.

Choose the first task your team can finish

Take one unanswered requirement from your list. Name the person who will resolve it, the information they need, and when the team will review the answer. Use that decision to start your action plan.

Write your next action