soc2pentest

A plain-English reference on SOC 2 for European vendors: who may issue the report, and what the penetration test is actually for.

Run the gap finder

SOC 2 · EU vendorsSheet 00 / cover

SOC 2 does not require a pentest. Your auditor still will.

A plain reference for European software and service companies whose customer will not sign without a SOC 2 report: what the report actually is, who is allowed to issue it, and what the penetration test is really evidencing.

Scope a SOC 2 penetration test Who issues what

OffSeq is a penetration-testing firm, not a CPA firm. It cannot issue a SOC 2 report of any type, and that boundary is stated on every page of this site rather than buried in a disclaimer.

Who issues whatSheet 01 / issuers

Eight documents, four different signatures

Most of the confusion about SOC 2 comes from treating several unrelated documents as one product. They have different authors, different subject matter and different rules about who may sign them. A tick marks the two OffSeq can actually deliver; a dash marks the six it cannot.

  1. SOC 2 report, type 1 or type 2

    Issued by
    A CPA firm, as an examination under the AICPA Statements on Standards for Attestation Engagements
    Opines on
    Whether controls relevant to security and, where selected, availability, processing integrity, confidentiality or privacy are suitably designed and – in a type 2 – operating effectively over a period
    OffSeq
    Cannot issue, sign or co-sign it. No security firm can.

  2. SOC 1 report

    Issued by
    A CPA firm, same standards
    Opines on
    Controls at a service organization that are likely relevant to user entities' internal control over financial reporting
    OffSeq
    Cannot issue it. Rarely what a SaaS buyer is asking for.

  3. SOC 3 report

    Issued by
    A CPA firm, same standards
    Opines on
    The same subject matter as a SOC 2 with far less detail, in a form that may be distributed freely
    OffSeq
    Cannot issue it – but it is the answer when a customer wants something shareable.

  4. ISAE 3000 (Revised) assurance report

    Issued by
    A practitioner bound by the IESBA Code and a firm-level quality management system
    Opines on
    The international equivalent of a SOC 2: assurance on subject matter other than historical financial information
    OffSeq
    Cannot issue it. Consulting work is expressly outside the assurance standards.

  5. ISAE 3402 assurance report

    Issued by
    The same kind of practitioner
    Opines on
    The international equivalent of a SOC 1 – controls relevant to user entities' financial reporting
    OffSeq
    Cannot issue it. Frequently confused with ISAE 3000; it is not the SOC 2 analogue.

  6. ISO/IEC 27001 certificate

    Issued by
    An accredited certification body, independent of any consultant who helped you build the system
    Opines on
    That an information security management system conforms to the standard
    OffSeq
    Cannot certify you, and would disqualify the body if it tried.

  7. Penetration test report and retest evidence

    Issued by
    An independent security testing firm
    Opines on
    What an attacker could actually reach in your product, how it was proven, and what changed after remediation
    OffSeq
    Ours end to end. Scope, testing, report, remediation advice and retest.

  8. Readiness and gap assessment against the trust services criteria

    Issued by
    Anyone competent. The AICPA publishes the criteria for use in attestation or consulting engagements
    Opines on
    Nothing – it is advice, not assurance. That is exactly why it may be bought from a security firm
    OffSeq
    Ours. Gap analysis, control design, evidence workstream, auditor selection support.

Sources for every line in this table are listed at the foot of the page. The two ticked rows are the whole of what a penetration-testing firm may honestly sell against a SOC 2 program; everything else needs an independent third party you appoint yourself.

The pentest questionSheet 02 / testing

Does SOC 2 require a penetration test?

No. It is worth being blunt about this, because most pages that rank for the question say the opposite, and the buyer who believes them then cannot explain the scope decision to their own auditor.

No trust services criterion names a penetration test. Your customer, your auditor and your own risk assessment all arrive at one anyway – which is why the honest answer is "not required, and you are still going to buy one".

  1. Your customer

    SOC 2 is bought because an enterprise buyer will not sign without it, and the same vendor review asks for a current third-party test report. In the EU that demand is now written upstream: NIS2 makes an entity responsible for "the overall quality of products and cybersecurity practices of their suppliers", and the implementing regulation puts "the right to audit or right to receive audit reports" into the supplier contract itself.

    Directive (EU) 2022/2555, Art. 21(2)(d) and 21(3) · Implementing Regulation (EU) 2024/2690, Annex point 5.1.4(e)

  2. Your auditor

    The trust services criteria are outcome statements. They describe what a control must achieve, not which procedure proves it, so the sufficiency of evidence is the service auditor's professional judgment. The AICPA has been unusually pointed about that lately, warning firms that lean on tooling "without applying the professional judgment required by our standards". For an internet-facing multi-tenant product, an independent test is the cheapest credible evidence there is.

    AICPA Professional Ethics Division and AICPA peer review guidance, Journal of Accountancy, April and May 2026

  3. Your own risk assessment

    Both the trust services criteria and the EU's own technical rules work the same way: you set the need, scope, frequency and type of security testing from a risk assessment, document what was tested and when, and remediate critical findings. If your risk assessment names the production platform as the crown-jewel risk and nothing in your evidence shows it was tested, the gap is in your own file before an auditor opens it.

    Implementing Regulation (EU) 2024/2690, Annex point 6.5 (security testing)

The long version, with the exact wording of each instrument, is in Does SOC 2 require a penetration test?. For scope and calendar, see SOC 2 penetration test: scope, timing and the report.

Readiness gap finderSheet 03 / worksheet

What will your auditor ask for, and what is missing?

Pick the categories in scope and mark where you are today. The worksheet returns the evidence a service auditor will request, the gaps it implies, and an honest split of who has to close each one. Nothing is sent anywhere.

Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.

The interactive worksheet needs JavaScript. The reference content it is built from is below: the categories you can put in scope, the seven control areas an auditor samples first, and who is able to close each kind of gap.

Categories in scope

  • Security. The common criteria. Always in scope, and the only category most customers actually read.
  • Availability. Capacity, resilience and recovery against a commitment you have published.
  • Confidentiality. Identifying confidential information and protecting it through to disposal.
  • Processing integrity. That processing is complete, valid, accurate, timely and authorized.
  • Privacy. Notice, choice, use, retention and disclosure of personal information.

Where you are today

  1. Multi-factor authentication on production and administrative access. Cloud console, VPN, code repository, CI/CD and the production database. No MFA on privileged access. This is the finding most likely to end an examination early, and the fastest one to fix.
  2. Centralized logging with alerting and a stated retention period. Authentication, privileged actions and configuration changes, kept long enough to investigate. No central logging. Detection, incident response and several access criteria all rest on it, so this blocks more than one control area.
  3. Periodic user access reviews that leave a record. Who reviewed which accounts, on what date, and what was revoked. No periodic access review. Expect a request for joiner, mover and leaver evidence across every production system.
  4. Vendor and sub-processor management. An inventory, a risk rating, and evidence you look at their assurance reports. No vendor management. Your own customers are doing this to you, and your auditor will ask what you do to the layer below.
  5. A documented incident response plan that has been exercised. Roles, severity levels, customer notification, and a dated tabletop or real incident write-up. No documented incident response. This also undermines the notification commitments in your customer contracts.
  6. Change management with review and approval on production changes. Peer review, an approval trail, and separation between who writes and who deploys. No change control on production. Expect this to be sampled heavily, because it is where operating effectiveness is easiest to disprove.
  7. Independent penetration test of the production platform. A dated third-party report, with evidence that critical findings were fixed and retested. No independent test. Nothing else in your evidence pack answers the question of what an attacker could actually reach.

Who closes what

  • You. The controls, the people who run them and the system description are yours. No consultancy and no platform can operate a control on your behalf and have it count.
  • OffSeq. Readiness and gap assessment against the criteria, control design, the evidence workstream, security awareness training, an incident response tabletop, and the penetration test and retest.
  • A CPA firm. The examination and the report. You appoint them independently; we can help you shortlist and brief them, and act as your technical counterpart during fieldwork.
Plan SOC 2 readiness
Categories in scope

A SOC 2 covers the security category plus any of four others you and your auditor agree to include. Each one you add brings its own evidence, its own controls and its own fieldwork hours.

SecurityThe common criteria. Always in scope, and the only category most customers actually read.

Where you are today

Answer honestly rather than aspirationally. "Partial" means the control exists but produces no evidence an outsider could read, which is the single most common reason fieldwork slips.

  1. Multi-factor authentication on production and administrative accessCloud console, VPN, code repository, CI/CD and the production database.

  2. Centralized logging with alerting and a stated retention periodAuthentication, privileged actions and configuration changes, kept long enough to investigate.

  3. Periodic user access reviews that leave a recordWho reviewed which accounts, on what date, and what was revoked.

  4. Vendor and sub-processor managementAn inventory, a risk rating, and evidence you look at their assurance reports.

  5. A documented incident response plan that has been exercisedRoles, severity levels, customer notification, and a dated tabletop or real incident write-up.

  6. Change management with review and approval on production changesPeer review, an approval trail, and separation between who writes and who deploys.

  7. Independent penetration test of the production platformA dated third-party report, with evidence that critical findings were fixed and retested.

Where the test sitsSheet 04 / calendar

The order the calendar actually runs in

The two report types are defined by what they opine on, not by how thorough they are. A type 1 covers the description and design of controls; a type 2 covers description, design and operating effectiveness over a period. That single distinction sets the whole schedule.

  1. Phase 01

    Readiness and gap assessment

    Map the criteria in scope to controls you actually have, and write down the ones you do not. Two to six weeks, depending on how much of the system description already exists.

    What you can show An internal gap list. Nothing an outsider can read yet.

  2. Phase 02

    Remediation and the penetration test

    Build the missing controls, then test the platform. Testing before remediation produces a report full of findings you already knew about; testing after produces evidence.

    What you can show A dated third-party test report, with critical findings fixed and retested.

  3. Phase 03

    Type 1 examination

    A CPA firm examines the description and the design of controls as at a point in time. Optional, and worth it mainly when a deal is blocked now and the observation window has not started.

    What you can show A report that opines on design only. Say so when you share it.

  4. Phase 04

    The observation window

    Controls have to run, and the evidence has to accumulate. Three months is the shortest window most auditors will accept for a first type 2; a full year is what a mature buyer expects.

    What you can show Access reviews, change tickets, alerts, training records – and the test report, dated inside the window.

  5. Phase 05

    Type 2 examination

    The examination covers description, design and operating effectiveness across the whole period. Fieldwork samples the evidence you have been collecting; it does not create it.

    What you can show The report enterprise security reviewers actually ask for.

  6. Phase 06

    Every year after that

    A new observation window opens as the last one closes, and the test is repeated. Retest after any significant change to the platform, not only on the anniversary.

    What you can show A report and a test both dated inside the last twelve months.

The type 1 and type 2 definitions above are the ones the international standard for service organization assurance uses, and the AICPA suite follows the same split. Detail, scope and the report's contents are in the scope and timing guide.

In EuropeSheet 05 / europe

Reading this from the EU changes the answer

SOC 2 can support enterprise buyers who request an assurance report. In the TED searches below, its name appears less often than ISO 27001. Check your buyers’ actual requirements and your applicable EU obligations before choosing an assurance programme.

E1

The GDPR already requires you to test

Article 32(1)(d) requires the controller and the processor to have "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing". Unlike SOC 2, that is a legal obligation, and it applies whether or not any customer asks.

E2

Your customer's audit right is already in the contract

Article 28(3)(h) requires the processor to "allow for and contribute to audits, including inspections", by the controller or an auditor it mandates. The NIS2 implementing regulation adds "the right to audit or right to receive audit reports" to supplier contracts for in-scope entities. A report you can hand over is usually cheaper than an inspection you have to host.

E3

EU technical rules name ISO/IEC 27001, not SOC 2

Implementing Regulation (EU) 2024/2690 states that its requirements "are based on European and international standards, such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401". SOC 2 appears nowhere in the instrument. If your buyers are European regulated entities rather than American enterprises, the certificate is the more useful document.

E4

A SOC 2 report is not a GDPR certification

Data protection certification under Articles 42 and 43 comes from a body accredited by the supervisory authority or the national accreditation body, and even then it "does not reduce the responsibility of the controller or the processor". No SOC report, and no ISO certificate, is a GDPR certification. Say that plainly when a customer asks you to conflate them.

Full-text mentions in TED procurement notices
Term searched in full textNoticesvs ISO 27001
ISO 27001 or ISO/IEC 270017,540100%
SOC 21492.0%
ISAE 3402771.0%
SOC 1720.95%
penetration test240.32%
ISAE 3000170.23%
Own measurement, 13 September 2026: full-text queries against the TED search API over 2,301,748 notices dated 1 January 2024 to 13 September 2026. These are full-text matches, including notice versions, rather than counts of unique buyers or mandatory requirements. Search wording and languages affect the results; private procurement is outside this corpus. Download the queries and count snapshot.

What we sellSheet 06 / scope of work

The honest scope of a security firm on a SOC 2 program

Published in full, because the fastest way to lose this audience is to be vague about it. If a vendor will not tell you where its work stops, ask why.

What OffSeq delivers

  • Penetration testing of the production platform, its APIs and its cloud configuration, with a report written to be read by an auditor and a customer, not only by an engineer
  • Retest evidence after remediation – the part enterprise reviewers check for and most reports omit
  • Readiness and gap assessment against the trust services criteria in your scope
  • Control design and the evidence workstream: what to collect, where it lives, and how it will be sampled
  • System description support, including subservice organizations and complementary user entity controls
  • Security awareness training and an incident response tabletop with a written record
  • Auditor selection support: what to ask a CPA firm about scope, sampling, independence and peer review results
  • Technical counterpart during fieldwork, so your engineers answer questions once instead of five times

What OffSeq cannot deliver

  • The SOC 2 examination, or a SOC 2 report of any type. Only a CPA firm performing the examination under the AICPA attestation standards can issue one.
  • A SOC 1 or SOC 3 report, for the same reason.
  • An ISAE 3000 or ISAE 3402 assurance report. Consulting engagements are expressly outside the international assurance standards.
  • An ISO/IEC 27001 certificate. That comes from an accredited certification body that must be independent of whoever helped you build the management system.

There is also no such thing as being "SOC 2 certified" or "SOC 2 compliant" – compliance is not a term the examination uses. If a vendor offers you either, that alone tells you how the report will read.

Talk to OffSeq about scope Run the gap finder first

GuidesSheet 07 / library

Four long answers

Each one is sourced to the instrument it describes, with the wording quoted where the wording is the point.

  1. Does SOC 2 require a penetration test?

    No criterion names one. Three other parties do, and one of them writes the report. Here is exactly where the expectation comes from and what it costs to ignore it.

    Read

  2. Who can issue a SOC 2 report in the EU?

    A CPA firm, performing an examination under the AICPA attestation standards. Not a platform, not a security firm, and not anybody selling you a certificate.

    Read

  3. SOC 2 or ISO/IEC 27001 for an EU vendor?

    One is an American report your US customers know by name. The other is the certificate European buyers actually write into tenders. The evidence for that, and how to choose.

    Read

  4. SOC 2 penetration test: scope, timing and the report

    What to put in scope, where the test lands relative to the observation window, and what the report has to contain before an auditor or a customer will treat it as evidence.

    Read

QuestionsSheet 08 / questions

Ten questions, answered without hedging

The ones that decide whether the project is worth starting.

Does SOC 2 require a penetration test?

No. No trust services criterion names a penetration test, and any page that says the standard mandates one is wrong. The expectation comes from three other places: the enterprise customer whose vendor review demands a current third-party report, the service auditor who has to judge whether the evidence for the criteria is sufficient, and your own risk assessment, which is what the criteria actually require you to test against.

Can OffSeq issue our SOC 2 report?

No, and neither can any other security firm or compliance platform. A SOC 2 report is an examination performed by a CPA firm under the AICPA attestation standards. OffSeq delivers the readiness work, the evidence workstream and the penetration test; you appoint an independent CPA firm for the examination.

Is there such a thing as being SOC 2 certified?

No. SOC 2 produces a report, not a certificate, and compliance is not a term the examination uses at all. A vendor promising to make you "SOC 2 certified" in a few weeks is describing something that does not exist.

Who can issue a SOC 2 report in Europe?

A CPA firm performing the examination under the AICPA attestation standards. Firms outside the United States do sign SOC 2 reports, usually as member firms of international networks. The AICPA has said publicly that where auditors are unlicensed, are not enrolled in peer review, or have not followed professional standards, it will act. Ask any prospective firm about its licensing and its peer review results before you engage it.

Is ISAE 3000 the same thing as SOC 2?

It is the closest international equivalent. ISAE 3000 (Revised) covers assurance engagements other than audits or reviews of historical financial information, which is where the SOC 2 subject matter falls. ISAE 3402 is the analogue of SOC 1, not SOC 2: it deals with controls at a service organization that are relevant to user entities' financial reporting. Getting that pair the wrong way round is the most common mistake in European vendor documentation.

Do we need SOC 2 or ISO/IEC 27001?

Start with the document your actual buyers require. The TED searches on this page find more ISO/IEC 27001 mentions than SOC 2 mentions, but they do not establish a universal rule for European buyers or cover private procurement. Review current tenders and customer questionnaires, then agree the assurance scope with the relevant certification body or CPA firm.

Does a SOC 2 report satisfy the GDPR?

No. A SOC 2 report is not a data protection certification; those come only from bodies accredited under Article 43, and even an accredited certification does not reduce the controller's or processor's responsibility. A SOC 2 can be useful evidence when a controller exercises its Article 28(3)(h) audit right, and the testing behind it helps demonstrate the Article 32(1)(d) obligation to test regularly – but it settles neither question on its own.

How recent does the penetration test have to be?

There is no rule, which in practice means twelve months. Enterprise security reviewers routinely reject a report dated more than a year ago, and for a type 2 the test needs to fall inside the observation period the report covers. Retest after any significant change to the platform rather than waiting for the anniversary.

Can we show the SOC 2 report to a customer?

Under an NDA, usually. SOC 2 reports are restricted to specified parties who understand the system and the services provided, which is why they are shared under agreement rather than published. If you need something you can put on a website or hand to anyone who asks, that document is a SOC 3: the same subject matter with much less detail, and general use by design.

How long does readiness take?

For a small SaaS team with cloud infrastructure and no prior program, plan six to nine months to a type 2: a few weeks of gap assessment, a couple of months of remediation and testing, then an observation window of at least three months. A type 1 can be reached considerably faster, and is worth doing only if a specific deal is blocked right now.

Sources

  1. Promises of 'fast and easy' threaten SOC credibility Journal of Accountancy · 2026 SOC reports are examinations performed by CPAs under the AICPA attestation standards; non-CPA-firm tool providers cannot attest; SOC 2 reports are restricted to specified parties; compliance is "a term never used in SOC 2 examinations".
  2. SOC 2 – audit and assurance topic page, including the AICPA notice on SOC service quality AICPA & CIMA The AICPA states it will act where auditors have not followed professional standards, are not enrolled in peer review, or are unlicensed.
  3. 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022) AICPA & CIMA · 2023 The five categories, established by the Assurance Services Executive Committee, published for use in attestation or consulting engagements.
  4. SOC 1 and SOC 3 topic pages AICPA & CIMA SOC 1 covers controls relevant to user entities' internal control over financial reporting; SOC 3 addresses the same subject matter as SOC 2 in less detail and is a general use report that can be freely distributed.
  5. ISAE 3000 (Revised), Assurance Engagements Other than Audits or Reviews of Historical Financial Information IAASB · 2013 Effective for reports dated on or after 15 December 2015. Consulting and advisory engagements are expressly not assurance engagements. The same document carries the ISAE 3402 scope and the type 1 and type 2 definitions.
  6. Regulation (EU) 2016/679 (General Data Protection Regulation) EUR-Lex · 2016 Article 32(1)(d) regular testing, Article 28(3)(h) audit and inspection right, Articles 42 and 43 on accredited certification bodies.
  7. Commission Implementing Regulation (EU) 2024/2690 EUR-Lex · 2024 Recital (3) bases the technical requirements on ISO/IEC 27001 and ISO/IEC 27002; Annex point 5.1.4(e) on audit rights in supplier contracts; Annex point 6.5 on risk-based security testing.
  8. Directive (EU) 2022/2555 (NIS2) EUR-Lex · 2022 Article 21(2)(d) and 21(3) on supply chain security and the cybersecurity practices of suppliers.
  9. TED notices search API Publications Office of the European Union · 2026 Search API documentation. The table links to the exact queries and count snapshot for 1 January 2024 to 13 September 2026.