Pentest, red team, scan, SOC 2, ISO 27001 — what's actually what

Ask five vendors for "a security assessment" and you will get five different things at five different prices. Ask a bank what they need from you and the answer often comes back as "a certificate," which is not a thing that exists for most of what they're actually asking about.

Most of the confusion comes from one place: two completely different kinds of thing get talked about as if they're the same.

• Testing activities — vulnerability scanning, penetration testing, red teaming. These are things somebody does to your systems.
• Frameworks and standards — SOC 2, ISO 27001, PCI DSS, POPIA, Joint Standard 2 of 2024. These are sets of expectations you are measured against.

A framework may tell you to test. A test is never a framework. Knowing which one you've been asked for saves you from buying the wrong thing — and from telling a client's bank something that isn't true.

This page explains each one plainly, and is equally clear about what we do and what we don't.

Part 1 — The testing activities

Vulnerability scanning

What it is: Automated software checks your systems against a database of known vulnerabilities — missing patches, outdated software versions, weak configurations, expired certificates — and produces a list ranked by severity.

What it's good at: Breadth and repeatability. A scanner can cover thousands of hosts overnight, and can run every week without complaint. It's how you spot the newly-published critical CVE sitting on your perimeter before someone else does.

What it can't do: A scanner finds known issues in individual components. It does not chain three medium findings into a full compromise, it does not understand your business logic, and it cannot tell you that a user on account A can read account B's invoices — because nothing about that looks like a vulnerability to a tool. Scanners also produce false positives that need a human to dismiss, and false negatives nobody notices.

Cadence: Continuous or monthly is normal. Quarterly is the compliance floor in several frameworks.

Penetration testing

What it is: A qualified human, working to an agreed scope and rules of engagement, actively attempts to break into a defined target — a web application, an API, an internal network, a mobile app — and then proves what they achieved.

The question it answers: "What can an attacker actually do to this system, and how bad is it?"

A pentest is coverage-based. Within the agreed scope, the goal is to find as much as possible and rank it by real-world risk. The tester uses scanner output as a starting point, then does the part a tool can't: chains findings together, escalates privileges, abuses business logic, and demonstrates genuine impact rather than theoretical severity.

What you get: A risk-ranked report of confirmed findings, evidence of exploitation, and remediation guidance a developer can act on. Not a list of maybes.

What it isn't: A pentest is not covert. The client knows it's happening, and the tester isn't spending effort staying hidden from your security team — that would waste the days you're paying for. It also isn't a permanent state. A pentest is a snapshot of a defined scope on a defined date. Ship a new feature next month and that scope has changed.

Cadence: Annually at minimum, plus after any significant change to the application or infrastructure.

Red teaming

What it is: A goal-based adversary simulation. Rather than "test this application," the objective is something like "get to the customer database" or "obtain domain admin" — and the team pursues it the way a real attacker would, across whatever paths are available: external systems, phishing, social engineering, physical access, credential abuse, lateral movement.

The question it answers: "If a competent attacker came for us, would we notice, and could we stop them?"

That's the crucial difference. A pentest tests your systems. A red team tests your detection and response — your monitoring, your SOC, your incident process, your people. It is entirely possible to pass a pentest with a clean report and still fail a red team badly, because nobody was watching the alerts.

How it runs: Covert, usually with only a tiny "white team" inside the organisation aware it's happening. Engagements run weeks to months rather than days. The deliverable is narrative-driven — the attack path, the points at which you should have detected it, mapped against a framework like MITRE ATT&CK — followed by a joint session with your defenders to work through what was and wasn't caught.

Who it's for: Organisations that already have a security team, monitoring in place, and a history of penetration testing. Red teaming an environment that hasn't been pentested is expensive and pointless — you'll find the front door open and learn nothing you couldn't have learned for a fraction of the cost.

The regulated version: In financial services, threat-intelligence-led red teaming has been formalised into frameworks — TIBER-EU from the European Central Bank, CBEST from the Bank of England, and Threat-Led Penetration Testing (TLPT) mandated under the EU's DORA regulation. These add a formal threat-intelligence phase, strict regulator oversight, and testing against live production systems. They're generally reserved for systemically important institutions.

Side by side

	Vulnerability scanning	Penetration testing	Red teaming
Driven by	Automation	A human tester	A human team
Approach	Breadth across known issues	Depth within an agreed scope	A specific objective, any route
Question	What's known to be wrong?	What can be exploited, and how badly?	Would we detect and stop a real attacker?
Tests your	Patching and configuration	Systems and applications	Detection, response and people
Covert?	No	No	Yes
Duration	Hours, continuous	Days to weeks	Weeks to months
Output	Ranked list of findings	Risk-ranked report with proven impact	Attack narrative and detection gaps
Relative cost	R	RR	RRRR

They are not competitors. A mature programme runs continuous scanning, tests properly at least annually, and red teams once the first two are working.

Part 2 — The frameworks and standards

None of these are things we can issue. All of them are reasons someone might send you to us.

SOC 2

What it is: An attestation report, not a certificate. A licensed CPA (accounting) firm examines your controls against the AICPA's Trust Services Criteria under attestation standard AT-C Section 205, and issues a formal report containing their professional opinion.

The terminology matters: There is no such thing as SOC 2 certification. The AICPA writes the standards but certifies nobody, and there is no pass/fail — even an adverse opinion produces a report. "SOC 2 certified" is common marketing shorthand and it's wrong. Auditors and enterprise security teams notice.

The five criteria: Security, availability, processing integrity, confidentiality and privacy. Security is the only mandatory one; the rest are included based on what you do and what your customers ask for.

Type I vs Type II: Type I assesses whether controls are suitably designed at a point in time. Type II assesses whether they operated effectively across a period. Type II is what most enterprise buyers want. There is no fixed AICPA minimum for that period, though reputable firms typically insist on at least three months for a first report and longer thereafter.

Where penetration testing fits: This is widely misstated, so precisely: the Trust Services Criteria do not mandate penetration testing. Criterion CC4.1 lists penetration testing as one example of an acceptable ongoing or separate evaluation, alongside independent certifications and internal audit. In practice, auditors overwhelmingly expect a scoped third-party test, and it is the most readily accepted evidence — but if you skip it, the burden is on you to show your alternative evaluations adequately address the risk.

ISO 27001

What it is: Unlike SOC 2, this genuinely is a certification. ISO/IEC 27001 is an international standard for an Information Security Management System (ISMS), and certification is awarded following an audit by an accredited certification body.

Current version: ISO/IEC 27001:2022, plus the 2024 amendment covering climate action. Certificates issued against the older 2013 version expired on 31 October 2025 — if yours lapsed, the route back is full recertification (Stage 1 and Stage 2 audits), not a transition audit.

Structure: Clauses 4–10 are the mandatory ISMS requirements — governance, risk assessment, management review, continual improvement. Annex A then offers a reference set of 93 controls across four themes: Organisational (37), People (8), Physical (14) and Technological (34).

Annex A is a menu, not a checklist. You are not required to implement all 93. You select based on your risk assessment and record every inclusion and exclusion, with justification, in your Statement of Applicability.

Where penetration testing fits: The standard does not name penetration testing as a hard mandate. The controls where auditors look for that evidence are A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance).

SOC 2 or ISO 27001? Broadly: SOC 2 is favoured by US buyers and is report-based, describing how your controls actually performed. ISO 27001 is more internationally recognised, including across Africa, Europe and Asia, and is certificate-based, confirming you run a functioning management system. Plenty of organisations eventually hold both. Neither replaces technical testing.

PCI DSS

If you store, process or transmit payment card data, PCI DSS applies — and it's the clearest illustration on this page of why scanning and pentesting are not the same thing, because the standard puts them in separate requirements:

• Requirement 11.3 — vulnerability scanning, at least quarterly and after significant changes. External scans must be run by a PCI SSC Approved Scanning Vendor (ASV). Internal scans must now be authenticated.
• Requirement 11.4 — penetration testing, at least annually and after significant infrastructure or application changes, human-led, by a qualified and independent tester, against a documented methodology. Critical findings must be remediated and retested.
• Segmentation testing — annually for merchants, every six months for service providers, where segmentation is used to isolate the cardholder data environment.

Where both apply, a QSA will expect evidence of both. One does not substitute for the other.

POPIA

South Africa's Protection of Personal Information Act doesn't prescribe testing methods, but Section 19 sets an obligation with a specific shape. A responsible party must secure personal information through appropriate, reasonable technical and organisational measures, and must take reasonable steps to:

• identify all reasonably foreseeable internal and external risks;
• establish and maintain appropriate safeguards against them;
• regularly verify that those safeguards are effectively implemented; and
• keep them updated as new risks emerge.

That third point is the one that matters here. POPIA doesn't say "penetration test," but it does require you to verify — regularly — that your controls actually work, rather than assuming they do. Independent technical testing is the most defensible evidence of verification. Section 19 also requires that measures have due regard to generally accepted information security practices.

Section 21 extends this: where an operator processes personal information on your behalf, a written contract must require them to maintain the same security measures. Which is exactly why your clients ask you for evidence.

Joint Standard 2 of 2024 (South African financial sector)

The one most South African organisations haven't read, and increasingly the reason they're being asked for security evidence.

Published by the FSCA and the Prudential Authority on 17 May 2024 and effective 1 June 2025, Joint Standard 2 of 2024 sets cybersecurity and cyber resilience requirements for South African financial institutions — banks, insurers, asset managers, retirement funds and more. Among other things, it requires institutions to regularly test all elements of their cyber resilience capability and security controls to assess vulnerabilities and determine overall effectiveness, and to mitigate cyber risk arising from third parties.

Part 3 — What PentestSA does, and what we don't

We think being clear about the second list is more useful than being vague about the first.

What we do

• Penetration testing — web applications, APIs, external and internal infrastructure, mobile applications, cloud environments.
• Vulnerability management — continuous scanning, triage, and tracking through to remediation.
• Targeted attack simulation — objective-driven adversary emulation testing detection and response.
• Retesting — verifying that what we reported has actually been fixed.
• Remediation support — working directly with your developers and engineers on the fix, not just the finding.

What we don't do

We do not issue SOC 2 reports. Only a licensed CPA firm can. We aren't one, and no penetration testing company is. What we can be is the independent technical specialist your auditor relies on — and there's a reason that role is separate. The AICPA treats penetration testing, vulnerability management and incident response as non-attest services that create an independence problem when performed by the same firm auditing the environment. Auditors therefore rely on external specialists for technical testing. Our independence from your audit is a feature, not a gap.

We do not issue ISO 27001 certificates. Certification comes from an accredited certification body following a formal audit. We're not one. We test the technical controls that sit behind Annex A.8.8 and A.8.29 and produce the evidence.

We are not your QSA or ASV. We can perform the Requirement 11.4 penetration testing; the assessment and scan attestation sit with the relevant certified parties.

We do not sell scanner output as a penetration test. Every pentest we deliver is human-led. Where we run automated tooling, it's a starting point, and we say so.

We do not certify anyone as "secure." No one can. A test is a point-in-time assessment of a defined scope. Any vendor offering a badge that says otherwise is selling you something that won't survive contact with a serious auditor.

What a letter of attestation actually is

Frequently requested, frequently misunderstood — and worth its own explanation, because the word "attestation" appears in both this and SOC 2, meaning different things.

A penetration test letter of attestation is a short, standalone document, suitable for sharing outside your organisation, confirming that an independent security firm conducted testing against a defined scope on a defined date, describing the methodology followed, and stating the current remediation position. It's what you give a client, a bank or a procurement team who needs assurance that testing happened — without handing over a full technical report containing exploitable detail about your systems.

It is not a SOC 2 attestation, which is a formal opinion issued by a licensed CPA firm under AT-C 205. Different document, different issuer, different meaning. Both are legitimate; conflating them in front of an auditor or a bank is the expensive kind of mistake.

For most South African vendor-security requests we see, the attestation letter plus a completed questionnaire is what's actually needed.

So which one do you need?

"A client or bank is asking for evidence before they'll sign."
Start by finding out precisely what they've asked for, in writing. In most cases it's a current independent penetration test report or attestation letter plus a vendor security questionnaire — not a framework certification. Ask before you budget.

"We're launching a new application."
Penetration test the application before go-live, then again after significant changes.

"We need to know what's exposed, all the time."
Continuous vulnerability management.

"We're pursuing SOC 2 or ISO 27001."
You'll need an auditor or a certification body — we're neither. What we provide is the independent technical testing they'll expect to see, scoped and documented to be handed straight over.

"We handle card data."
Quarterly ASV scanning and annual penetration testing under PCI DSS, plus segmentation testing where applicable. Both, not either.

"We want to know if we'd actually catch an attacker."
Targeted attack simulation — provided you already have monitoring, a response process, and a testing history behind you.

"We're not sure."
That's the most common answer, and it's fine. Book a scoping call and we'll help you work out what's actually being asked for.

FAQ

Is SOC 2 a certification?
No. It's an attestation report issued by a licensed CPA firm expressing an opinion on your controls against the Trust Services Criteria. There's no certificate and no pass/fail. ISO 27001, by contrast, is a genuine certification issued by an accredited certification body.

Does SOC 2 require a penetration test?
Not strictly. The Trust Services Criteria name penetration testing as one example of an acceptable evaluation method under CC4.1, alongside independent certifications and internal audit. In practice auditors overwhelmingly expect one, and it's the most readily accepted evidence.

Does ISO 27001 require a penetration test?
Not as an explicit mandate. Controls A.8.8 and A.8.29 are where auditors look for evidence of technical vulnerability management and security testing, and independent testing is the usual way that evidence is produced.

Is a vulnerability scan a penetration test?
No. A scan is automated and identifies known issues. A penetration test is human-led and demonstrates what can actually be exploited. PCI DSS treats them as separate requirements for exactly this reason.

How often should we test?
At least annually, and after any significant change to your applications or infrastructure. Several frameworks and most client contracts assume a report no older than twelve months.

Can you make us SOC 2 or ISO 27001 compliant?
No — and be cautious of anyone who says they can, because the firm doing your audit generally can't be the firm that built your controls. We provide the independent technical testing and evidence those processes rely on.

Do South African banks require SOC 2?
It varies considerably, and it's worth confirming rather than assuming. Some ask for SOC 2, some for ISO 27001, and many are satisfied with a recent independent penetration test report and a vendor security questionnaire. Since Joint Standard 2 of 2024 took effect on 1 June 2025, requests of this kind increasingly originate from a regulated institution managing its third-party risk — so asking which specific requirement is being met usually clarifies matters quickly.