I’m underselling SOC2. It assures some things pentests don't:
* consistent policies for who in the company gets access to what
...
That's a start. Of course, having policies raises a new question -- how well are they practiced? To what degree are they:
a. discoverable via internal tools?
b. descriptive and understandable (the policies use terminology that maps to the business processes clearly)?
c. measured?
d. internalized by employees as part of the culture?
e. enforced (as desired)?
f. externally reported (e.g. to downstream customers)?
g. reviewed when appropriate?
h. adjusted or removed as needed?
There are some spectacular failure modes of policies in the real word. Here are five attributes that fit together nicely into a mosaic of dysfunction:
* Everyone has to take a sleep-inducing thirty minute training.
* Policy compliance is "tracked" with a spreadsheet on an ad-hoc basis.
* Everyone in the organization has to "check off" that they comply, starting at the bottom and working up the chain to El Jefe.
* If something hits the fan and you need someone to blame, follow the paper trail and blame the people who incorrectly attested to policy compliance.
* Virtually anyone could fail compliance if you haul out the microscope. This is a feature, not a bug. Now you have a convenient and official way to get rid of people you don't like for arbitrary reasons.
This is stylized, yes, but not too far off the mark at some places.
One of the main points of real audits like SOC2 type II are about validating enforcement of the controls outlined as policies. So the policy that only employees with job role Z can sign onto System Y would be checked by summarizing the login audit logs for Y, and verifying that all the names on the list. Other policies might require verification by reviewing all or some auditor selected subset of occurrences to verify. Some details of some policies cannot be fully verified. As long as that risk is known and documented, it is not necessarily a problem.
SOC2 audit reports provide a high level version of reporting to downstream customers, without necessarily revealing the full details of the policy. (Sufficiently important customers could always insist on seeing the actual policy documents, if the reports don't satisfy them).
But some of your remaining considerations are somewhat outside the scope of SOC2. And they can be tricky problems.
a. discoverable via internal tools?
b. descriptive and understandable (the policies use terminology that maps to the business processes clearly)?
c. measured?
d. internalized by employees as part of the culture?
e. enforced (as desired)?
f. externally reported (e.g. to downstream customers)?
g. reviewed when appropriate?
h. adjusted or removed as needed?
There are some spectacular failure modes of policies in the real word. Here are five attributes that fit together nicely into a mosaic of dysfunction:
* Everyone has to take a sleep-inducing thirty minute training.
* Policy compliance is "tracked" with a spreadsheet on an ad-hoc basis.
* Everyone in the organization has to "check off" that they comply, starting at the bottom and working up the chain to El Jefe.
* If something hits the fan and you need someone to blame, follow the paper trail and blame the people who incorrectly attested to policy compliance.
* Virtually anyone could fail compliance if you haul out the microscope. This is a feature, not a bug. Now you have a convenient and official way to get rid of people you don't like for arbitrary reasons.
This is stylized, yes, but not too far off the mark at some places.