Remember to use the correct subject prefix depending on what you need:
- “Feature” for new features, for example: Feature - PDF Exports for Risks
- “Bug” when you think you have spotted a bug, for example: Bug - Risk Calculation
- “Support” when you need help with something, for example: Support - Compliance Package Imports
If you want to communicate something to us in private, please send us an email to email@example.com
IMPORTANT! Select all this text and remove it from your post before submitting it
i think you forgot to write someting on the body of the post and left the template instead?
Looking for anyone that has worked on importing SOC 2 risks into ERamba and has the template to share so I can import it instead of re-inventing the import from scratch.
Thanks in advance.
Which “risks” are you looking for? From a guidance/requirements perspective, there are Criteria (more or less requirements) and Points of Focus (things to consider when determining whether the Criteria has been met). The “risks” can be documented at either the Criteria or Point of Focus level, depending on what floats your particular boat. The risks are often specific to your environment, thus, aren’t necessarily things that can come from a can - at minimum, if you know your controls, then you can figure out the risk that sits in the middle…
Thanks David for your response. With what you stated above, would you link your SOC control to the TSC in some way. e.g. CC6.8: The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.
I suppose it depends on how detailed you want to be with it. When you look at an actual SOC 2 report, you will simply see a mapping of the Criteria (the CC6.8) to the one to many controls that satisfy the criteria. If you’re running your program internally and relying on your auditors or some other function to complete the mapping, then that should be absolutely fine to do.
When you look at what the auditor has to do though, the Points of Focus that I mentioned turn into their checklist to help them figure out what controls need to be there. For CC6.8 that you listed, there are 5 things that they are supposed to consider/look at to determine whether you “pass” CC6.8. Thus, in their work papers they will link Criteria -> Point of Focus -> Control, thus, if you want, you could do the associations that way yourself. I’m probably over complicating this for you - below are the Points of Focus for 6.8. I’ve also uploaded a file that you can easily make into a Compliance Package here if you want to work with it.
- Restricts Application and Software Installation—The ability to install applications and software is restricted to authorized individuals.
- Detects Unauthorized Changes to Software and Configuration Parameters—Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software.
- Uses a Defined Change Control Process—A management-defined change control process is used for the implementation of software.
- Uses Antivirus and Anti-Malware Software—Antivirus and anti-malware software is implemented and maintained to provide for the interception or detection and remediation of malware.
- Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software—Procedures are in place to scan information assets that have been transferred or returned to the entity’s custody for malware and other unauthorized software and to remove any items detected prior to its implementation on the network.
Thanks David. Very helpful. This drives my controls but no real need to link to rather only as a reference. Got it. Thanks.
I created a package for SOC 2 and successfully loaded it in to eRamba. I cannot share it here but have no problem sharing for those who want it. This is with many thanks to David Schroch.
@david.schroth is the man to go for soc2
Couple more things I just thought of with what I posted -
- The file I uploaded covers all 5 Principles - Security, Availability, Confidentiality, Processing Integrity and Privacy. Security is addressed by CCs 1-9 (CC=Common Criteria) and is the base requirement. The other 4 are optional depending on what is in scope for your SOC 2.
- Some of the Points of Focus within the Common Criteria (CC1-9) are also applicable only to a specific Principles and would be not applicable (i.e. in CC2, there are items about communicating changes to confidentiality and privacy commitments that would not be relevant if Confidentiality/Privacy was not in scope).
Can you offer some advice on how you went about creating the compliance package for SOC2 please. I got the Excel spreadsheet from David S but unsure where to go from here.