RD SecurityDE (Deutsch)
Why nowSelf-checkServicesSOC 2 & ISO 27001PricingFAQBook a scoping call (opens Google Calendar in a new tab)
Book a scoping call (opens Google Calendar in a new tab)

SOC 2 and ISO/IEC 27001 explained for startups and small software companiesA strong foundation. Not the whole picture.

SOC 2 and ISO/IEC 27001 are valuable, and your customers may ask for them. They answer one important question about your security. A penetration test answers another. Here is how we see them fitting together.

How to read a reportBook a scoping call (opens Google Calendar in a new tab)

We sell readiness support and penetration tests. Our interest in this topic

two different questions
SOC 2 and ISO/IEC 27001

Are our security controls and processes defined and working as described?

Penetration test

What can skilled testers exploit in our product, within an agreed scope and time?

They look at different things. Neither replaces the other.

~/what-they-give-you

First, what these frameworks do well.

SOC 2 is an assurance report from a licensed CPA under AICPA standards, rather than a certificate. Certification to ISO/IEC 27001 covers a management system. Both are widely recognized, and for good reason.

  • Structure

    Security gets owners, documented risk decisions, corrective actions and regular management attention.

  • Outside review

    A qualified third party examines your controls or management system, instead of you assessing yourself.

  • Evidence buyers can read

    A report or certificate gives customers something concrete to review, which is more than a questionnaire answer.

  • A shared language

    Customers, auditors and partners understand these frameworks, which makes security conversations easier.

“Certification alone does not secure systems, prevent incidents, or eliminate human error. What it does provide is a framework that makes information security manageable […]”
Erin Casteel, “ISO/IEC 27001 as a market entry ticket and trust as an enabler to trade”, ISO/IEC JTC 1/SC 27 Journal 2026, Issue 1, p. 42, writing about ISO/IEC 27001. The author's view.

~/scope

A report speaks for its scope.

In SOC 2, management defines the scope and the auditor reviews whether it is appropriate and accurately presented. An ISO/IEC 27001 scope can cover a whole company or a defined part of it.

A focused scope is normal and often sensible. It just means systems outside it are not what the report speaks to, so it is worth reading the boundary.

Web appAPICustomer dataAdmin toolSupport toolCloud accountStaff laptopsTest serverInternal apps

3 of 9 systems in this example scope. Covers the product itself. Common and legitimate for a focused first report.

Systems reporting4 of 6
  • Cloud account AChecks passing
  • Code repositoryChecks passing
  • Identity providerChecks passing
  • Staff laptopsChecks passing
  • Cloud account BNot connected: no data
  • New test serverNot connected: no data

An invented example, not based on any product.

~/connected-tools

A dashboard reports on what's connected.

Compliance platforms save real time by collecting evidence automatically. They report on the systems and accounts connected to them, so the connected list matters.

  • A new system or account may not be connected yet.
  • A connection can stop syncing, so it is worth checking regularly.
  • Some systems are left out for good reasons, such as a sandbox. Some platforms document that auditors can see out-of-scope decisions. This varies by platform and action, so check yours.

A simple habit helps: compare your connected list against what you actually run.

~/sampling

Audits test samples.

Auditors commonly test a sample instead of every item, and expand it when they find deviations. This is standard, well-established audit practice for judging whether a process works.

A sample is designed to give confidence about a process. It is not designed to examine every account, device or line of code.

Illustrative only: 25 items picked from 120. Real sample sizes depend on the population and method.

~/timing

Reviews happen at intervals. Your product keeps moving.

A SOC 2 Type 2 report covers a stated past period. ISO/IEC 27001 certificates often run for three years with surveillance audits in between, as in the BSI IT-Grundschutz scheme, for example. Meanwhile, a software team may ship every week.

Audit period
Report issued
  • New feature shipped
  • New integration added
  • Dependency updated

These changes may be covered by a later review. Until then, your own processes and testing are what speak to them.

~/two-lenses

Controls and exploits are different questions.

A control review asks whether safeguards exist and operate. It isn't designed to try changing a number in a web address to see whose data comes back. That kind of check is part of a penetration test.

Control review

  • Multi-factor login required
  • Data encrypted at rest
  • Logging enabled
  • Access reviewed quarterly

All of these can be in place, and that is good.

penetration test, logged in as customer A
$ curl -s -H "Authorization: Bearer $A" \
    app.example.com/invoices/1042 | jq .owner
"Customer B"

This can still exist, because it is a different question. An invented example.

~/together

Each one does its own job.

Some customers and auditors also ask for a penetration test, so check whether yours expects one. Its results can feed into your compliance work. A penetration test is a snapshot, and it cannot prove that no other flaws exist.

TopicSOC 2ISO/IEC 27001Penetration test
Main questionDo the described controls meet the criteria?Is security run as a working management system?What can testers exploit within the agreed scope?
Performed byA licensed CPA, under AICPA standardsA certification bodySecurity testers
You receiveAn attestation reportA certificate with a stated scopeFindings with proof and fixes
Looks atControls, at a point in time or over a periodProcesses, risks and controlsAgreed systems, during the test window

~/how-to-read

Read a report or certificate, and leave with useful questions.

Go through each item in your own report or a supplier's. Mark what you can answer, and get a question list ready to send. It helps you read the document. It doesn't rate anyone's security.

What are you reading?
Whose is it?

SOC 2 report

Type and period

Where to look: Opening pages and the auditor's opinion

Type 1 covers control design at one date. Type 2 also tests whether controls worked over a period, commonly 3 to 12 months. A bridge letter is the company's own unaudited statement about the time since.

You could ask: Is this a Type 1 or Type 2 report, which period does it cover, and is a newer report or a bridge letter available?

Categories covered

Where to look: Auditor's opinion and system description

Security is always included. Availability, Confidentiality, Processing Integrity and Privacy are optional.

You could ask: Which Trust Services categories are covered, and do they include what we rely on you for?

System description

Where to look: System description, usually the longest section

Written by management. Check that it names the product and systems you actually use.

You could ask: Does the report cover the product and the systems that handle our data? Is anything we use outside its scope?

Auditor's opinion

Where to look: Auditor's report

An unqualified opinion is a clean one, though not a guarantee of security. A qualified, adverse or disclaimed opinion calls for a closer read.

You could ask: What type of opinion did the auditor give? If it was not unqualified, what was affected and what has changed since?

Exceptions

Where to look: Tests of controls and results (Type 2 only)

An exception is not automatically bad, and a clear account is useful. Read what was found and how management responded.

You could ask: Which exceptions were noted, and what is the current status of each?

Subservice organizations

Where to look: System description

These are providers the company relies on, such as cloud hosts. With carve-out, the auditor did not test their controls, and the report may list controls it assumes they run. With inclusive, the auditor did.

You could ask: Which subservice organizations are carved out, how do you review them, and do any of them handle our data?

What customers must do

Where to look: Usually the system description, under “Complementary user entity controls”

These are controls customers are expected to run on their side for the report's controls to be effective.

You could ask: Which complementary user entity controls apply to us, and are any especially important for our setup?

Who issued it

Where to look: Auditor's report and signature

Note the signing firm and the attestation standard named. Licence and peer review details usually sit outside the report.

You could ask: Which firm issued the report, and can you share its licence and peer review details if we need them?

Separate security testing

Where to look: Often outside the SOC 2 report

A SOC 2 report may or may not mention a penetration test. If one matters to you, ask separately.

You could ask: Do you have a recent penetration test? If so, what were its scope and date, and can you share a summary?

$ ./next-step

Prepare for the audit. Add a penetration test where it helps.

We help small teams prepare for SOC 2 and ISO/IEC 27001, and we test products using methods real attackers use, within an agreed scope. You can buy either one on its own.

Book a readiness call (opens Google Calendar in a new tab)See penetration tests

or email crew@rivedrive.com

Our interest in this topic. This page promotes our services and gives general information. We sell services relating to these frameworks, namely readiness support, including setting up compliance platforms, as well as penetration tests. We don't perform certification audits or issue SOC 2 reports. We have no partnership with any compliance platform or auditor and receive no commission from them. Nothing here is audit or legal advice, and practice varies between auditors and tools. We have no affiliation with AICPA, ISO or IEC.

Sources