Our company has multiple product, SaaS, and application specific managed service offerings. One of those offerings is ISO 27001 certified. I am in the process of implementing Eramba. Our plan is to expand the scope of our certification to include the other offerings. Though all offerings are subject to the same ISMS and policies, there are variances in deployment, security posture, control implementation, etc. My objective is to manage the compliance and risks for each offering independently where necessary, but leverage the common components as well, all within a single instance of Eramba. My thought at the moment is to create unique internal controls and risks for each of the offerings with a name that is prefixed by the offering ID. I don’t see any specific Eramba feature for this. Thoughts? Suggestions?
You’re absolutely thinking down the right path - and there isn’t one fully correct answer as quite frankly “it depends”.
At a high level, you’ll need to set up a compliance package for each individual compliance effort - ISO, SOC, etc. Where there are two or more tracks of compliance, you may want to look at ISO - App A, ISO - App B, etc., as the compliance packages so you can individually measure their compliance.
When you get to controls, there’s a few considerations with respect to combining. I usually have the “people, process and technology” should have at least 2/3 that are the same to consider combining the control. However, there’s other nuances to consider when it comes to maintenances and audits.
Speaking of maintenances and audits - you can write a LOT of controls with narrowly scoped maintenance/audits, or you can write FEW controls with broadly scoped maintenance/audits. For example, with password controls you could have the following strategies:
- Few Controls → Enterprise Password Configuration → Audit steps = review the following (or sample of) these twenty different systems
- Lots of Controls → App A Password Configuration, App B Password Configuration, Infrastructure Password Configuration and so on.
If a single person is performing the maintenances and audits, then it may make more sense to combine them, except in the scenario where an immature application will sink the entire control (i.e. App B, not in scope for a current ISO cert fails, the related control for App A, which is in scope, will also report as failed).
If multiple parties are performing maintenances/audits, it would make more sense to break them up as it’s not great to collaborate (i.e. 10 apps to one person and 10 apps to another person for testing) - splitting those into two controls will give you one neck to wring for each.
I suspect you’ll end up using a blend of the approaches across your environment and it’s a complete judgement call that you’ll probably get set up one way, decide you hate it, burn it down and do it again at least once before you’re happy with how it works. GRC is hard in that way…
Ultimately, that’ll leave you with the ability to associate a full stack of controls to a particular requirement. On the password front, that item might have an enterprise network SSO password control, an application user password control and a linux systems run by joe’s department password control that make up the three aspects of password management. That’s a judgement you’ll have to make when doing compliance analysis for the scope of each system/compliance package.
Thank you for the guidance. I had not considered establishing separate compliance packages (e.g. ISO) for each of the three offerings. I believe that will be my approach. I had expected some number of common controls, and other unique controls per offering.