4 ms·

> As a compliance person, SOC2 says that all change requests must have an associated ticket Does soc2 actually say this? IIRC their spec docs are proprietary s

> As a compliance person, SOC2 says that all change requests must have an associated ticket Does soc2 actually say this? IIRC their spec docs are proprietary so chumps like myself can’t actually read them. But a (imo great) SOC2 auditor I worked with previously allowed us to treat GitHub PRs as their own sufficient justification. We still used Jira for most, but for minor fixes, quick upgrades, no Jira necessary. A former coworker said they did the same at a previous job. I think, in this particular case, it isn’t SOC2’s fault, it is the fault of auditors who are afraid to not just do what everyone else does.

red-iron-pine 3y ago
the SOC requirement is that any change can 1) be looked at before happening, and 2) there is an audit trail. A PR generally works because it's auditable and there may not be an impactful change. "change request" is often a specific term in things Project Mgmt, SDLC, etc.
kstrauser 3y ago
Sigh. I don't have the docs in front of me, and even if I did, darned if I'm touching those diabolic tomes without a 10-foot pole and a paycheck. But they do say something along the lines that all change requests have to have some kind of a ticket. The good/bad part is that it doesn't specify exactly what that means. If you can find an enlightened auditor who accepts an explanation in the PR, awesome! There's no guarantee that the _next_ auditor will see it the same way. The whole audit process was a back-and-forth with explaining why we think our controls satisfy the request, and the end result was a clean report. > it isn’t SOC2’s fault, it is the fault of auditors who are afraid to not just do what everyone else does. There's some liability for them if they're too lax. Suppose a breach happens and a given control, as written in the spec, would have prevented it. It could come back on the auditor who signed off on a clever interpretation of that control.
- jollyllama 3y ago
  I haven't worked on anything that had to adhere to that standard, but I also have yet to work somewhere where a "Change Request" was a very specific thing related to workflows that may or may not involve software, i.e. hardware. A pull request rarely had relation to a proper Change Request.
  - kstrauser 3y ago
    A control that results in a paper trail without making anything materially better, but must still be obeyed to the letter because a certification depends on it? Why, I've never heard of such a thing, I do declare!
TheNewsIsHere 3y ago
It depends what’s in scope and the control being evaluated. For example, if your SDLC/release and infrastructure processes the environment(s) that are built from them are in scope of your SOC2 audit, then a change to the code deployed to the in-scope environment must meet a defined policy for change control. Auditors aren’t eager to accept “there is no SDLC,” or “our change control policy is to deploy to production whenever.” A lot of SOC2 is hand waived as paperwork, but the point is that an organization (and their independent auditor) can show evidence that they have established certain processes and controls, and that they can demonstrate compliance with their word. (This belies the tension that some use to discredit independent auditors: that the client pays the auditor for their report. What’s less well understood is that the auditor has a much greater vested interest in being honest, and that they’re going to get questioned if a matter ever goes to court. No one client is worth losing the entire firm. There are, of course, bad auditors just as there are bad developers, admins, accountants, etc.) I spent time working in compliance and led the inaugural SOC2 Type 2 audit at a household name. These days I spend my time primarily on infrastructure.

red-iron-pine 3y ago

the SOC requirement is that any change can 1) be looked at before happening, and 2) there is an audit trail. A PR generally works because it's auditable and there may not be an impactful change. "change request" is often a specific term in things Project Mgmt, SDLC, etc.

kstrauser 3y ago

Sigh. I don't have the docs in front of me, and even if I did, darned if I'm touching those diabolic tomes without a 10-foot pole and a paycheck. But they do say something along the lines that all change requests have to have some kind of a ticket. The good/bad part is that it doesn't specify exactly what that means. If you can find an enlightened auditor who accepts an explanation in the PR, awesome! There's no guarantee that the _next_ auditor will see it the same way. The whole audit process was a back-and-forth with explaining why we think our controls satisfy the request, and the end result was a clean report. > it isn’t SOC2’s fault, it is the fault of auditors who are afraid to not just do what everyone else does. There's some liability for them if they're too lax. Suppose a breach happens and a given control, as written in the spec, would have prevented it. It could come back on the auditor who signed off on a clever interpretation of that control.

jollyllama 3y ago
I haven't worked on anything that had to adhere to that standard, but I also have yet to work somewhere where a "Change Request" was a very specific thing related to workflows that may or may not involve software, i.e. hardware. A pull request rarely had relation to a proper Change Request.
- kstrauser 3y ago
  A control that results in a paper trail without making anything materially better, but must still be obeyed to the letter because a certification depends on it? Why, I've never heard of such a thing, I do declare!

TheNewsIsHere 3y ago

It depends what’s in scope and the control being evaluated. For example, if your SDLC/release and infrastructure processes the environment(s) that are built from them are in scope of your SOC2 audit, then a change to the code deployed to the in-scope environment must meet a defined policy for change control. Auditors aren’t eager to accept “there is no SDLC,” or “our change control policy is to deploy to production whenever.” A lot of SOC2 is hand waived as paperwork, but the point is that an organization (and their independent auditor) can show evidence that they have established certain processes and controls, and that they can demonstrate compliance with their word. (This belies the tension that some use to discredit independent auditors: that the client pays the auditor for their report. What’s less well understood is that the auditor has a much greater vested interest in being honest, and that they’re going to get questioned if a matter ever goes to court. No one client is worth losing the entire firm. There are, of course, bad auditors just as there are bad developers, admins, accountants, etc.) I spent time working in compliance and led the inaugural SOC2 Type 2 audit at a household name. These days I spend my time primarily on infrastructure.