SOC 2 - Security Consultants
- SOC 2 has two distinct workstreams: making the controls exist technically, and evidencing that they operate. They need different skills.
- A compliance consultant designs and documents. A security consultant or engineer builds and configures. Most programmes need both.
- The most common gap is a policy that describes a control nobody has actually implemented in the systems.
- Penetration testing is a separate specialist engagement, expected alongside SOC 2 by most buyers, and normally costs $4,000 to $25,000.
- Passing the examination and being secure are related but not identical. Scope the work so you get both.
Two kinds of work sold under one heading
SOC 2 involves two kinds of work that are frequently sold under one heading. The first is compliance work: setting scope, writing policies that describe your company accurately, deciding what evidence proves each control, and preparing for examination. The second is security work: actually configuring the access controls, the logging, the alerting, the encryption and the change management pipeline so the controls described are the controls that run.
A programme that buys only the first produces a well-documented company that cannot show the evidence. A programme that buys only the second produces a secure company that struggles to explain itself to an auditor. Most companies need both, and understanding which one you are short of is the first useful step.
What does a SOC 2 security consultant do?
The technical workstream typically covers the following.
| Area | What the work involves |
|---|---|
| Identity and access | Single sign-on, multi-factor authentication, role definitions, joiner and leaver processes, and the periodic access review that produces the evidence |
| Logging and monitoring | Centralised logs, retention periods that match your policy, alerting on the events your controls claim to detect |
| Change management | Pull request approvals, separation between the person who writes a change and the person who approves it, deployment records that can be sampled |
| Vulnerability management | Scanning, a defined remediation timescale by severity, and records showing the timescale was met |
| Encryption | Data at rest and in transit, key management, and evidence of both |
| Vendor and subprocessor oversight | An inventory, a review cadence, and records of the reviews |
| Incident response | A plan that has been tested, and records of real incidents handled under it |
| Backup and recovery | Where Availability is in scope, tested restores rather than configured backups |
Why it is a specialist job
None of this is exotic. What makes it a specialist job is that each item has to produce evidence a sampling auditor can test across a period, which changes how you would build it if you were only thinking about security.
Where the two workstreams meet
The join is the point where most programmes fail, and it is a documentation problem rather than a technical one.
A policy says access is reviewed quarterly. The engineering team performs an access review, but it is done ad hoc in a spreadsheet that is overwritten each time, so no record of the first two quarters exists. The control was operating. The evidence was not retained. In a Type 2 examination, those are the same outcome.
The reverse is just as common. A policy describes a formal change approval process, and the engineering team, reasonably, has never followed it because it was written by someone who did not know how the deployment pipeline works. The first engineer interviewed says so, and the exception is recorded.
Avoiding both requires the compliance side and the engineering side to design the control together, which is why we do not treat the two as sequential phases. Our implementation service covers both.
Do you need a penetration test?
In practice, yes. Penetration testing is not required by the Trust Services Criteria in explicit terms, but almost all enterprise buyers expect to see recent results alongside a SOC 2 report, and many auditors will ask about your vulnerability management programme in a way that assumes one exists.
A penetration test for a standard software application typically costs $4,000 to $25,000 depending on scope, with early-stage companies running a single web application at the lower end. It is a separate specialist engagement from both your consultant and your auditor. Ask any consultancy how they handle it: whether they subcontract, coordinate a third party, or leave it to you. All three are reasonable answers. Silence on the point is not.
Does passing SOC 2 mean you are secure?
Not by itself, and it is worth being honest about this because your buyer's security team already knows it.
SOC 2 tests whether the controls you described operated as described. If the control set you scoped was thin, the report can be clean and the company can still have real weaknesses. This is why sophisticated buyers read the report rather than checking that it exists, and why they ask follow-up questions about what sits behind a particular control.
The practical implication for scoping is that a control set designed only to produce a clean opinion tends to produce more questions from buyers than one designed to describe a security programme that genuinely runs. The second costs a little more to build and considerably less to explain.
How to scope the two together
Decide first who is doing the engineering. If you have a capable platform or infrastructure team, the technical workstream can sit with them, and the consultancy work becomes design, documentation, evidence framework and project management. If you do not, you need either a security consultancy alongside the compliance one, or a firm that covers both.
Then agree, item by item, who owns each control. A written responsibility matrix at the start of the engagement prevents almost every argument that happens later. It is a standard output of our readiness and gap assessment.
What to do next
Work out which of the two workstreams you are short of. If your systems are well built but nothing is written down, you need compliance help. If your documentation is fine but the controls do not exist in the systems, you need engineering help. Most companies are short of one and think they are short of the other.
Our free readiness diagnostic will point you at the answer, and the SOC 2 service page sets out how we run both sides together.
References
FAQ
Is a SOC 2 security consultant the same as a compliance consultant?
Not usually. Compliance work is scope, policy, evidence and audit preparation. Security work is configuring the systems so the controls run. Some firms cover both, and you should check rather than assume.
Do I need a penetration test for SOC 2?
The criteria do not name it explicitly, but most enterprise buyers expect recent results and most auditors will ask about vulnerability management. Budget $4,000 to $25,000 depending on scope.
Can my engineering team do the security work?
Often yes, if the controls are designed with the evidence requirement in mind from the start. The common failure is a control that works but leaves no retained record.
Does a clean SOC 2 report mean we have no security weaknesses?
No. It means the controls you scoped operated as you described them. A thin scope produces a clean report and unanswered buyer questions.
Which comes first, the security work or the documentation?
They should be designed together. Writing policies before the controls exist produces documents nobody follows, and building controls without the evidence requirement produces work that has to be redone.
About Hael
Hael is an advisory firm specialising in AI governance and security compliance. We take companies through SOC 2, ISO 27001, ISO/IEC 42001 and the EU AI Act, from first assessment to report, and maintain the position afterwards. We do the work rather than only advising on it, and every engagement has a named practitioner and an agreed scope, timetable and fee. On engagements involving regulated financial services firms we work alongside Buckingham Capital Consulting, the partner firm that has advised payment and e-money firms on authorisation and compliance since 2013.
This guide is general information and is not professional advice on your particular circumstances.