Curious to see how you’ve handled this situation. We leverage Software-as-a-Service (SaaS) applications, such as Salesforce. To me, Salesforce is technically a third party (supplier) that we have a contract with. However, Salesforce is also a piece of software that certain teams within our company use, so it is also an asset.
If I only create Salesforce as a third party, I miss out on being able to link Salesforce (the asset) to related business units and tie it to any related assets.
How are you handling this within the risk management module? Do you create both a third party and an asset?
I think there is no good or wrong here , it happens to me (personally) that i struggle defining risks in terms of assets, for some reason is a lot easier for me to document them as third parties or business processes, but i’ve seen colleagues having the exact opposite approach…one of those philosophical grc questions perhaps…?
Some context probably would be helpful. I am in the process of documenting our business units, their processes, and the associated tools/technologies and suppliers they use in Eramba as part of our overall Business Continuity/Disaster Recovery efforts.
So, I was thinking through this in that lens - What are the risks to the business if certain assets (applications, etc.) are unavailable?
I like Barry’s explanation of using both an asset and a third party. Might try that route…
Any other suggestions/ideas on how to do this are appreciated!
Here’s another possible scenario - What about cloud service providers, such as Amazon Web Services? AWS is technically a datacenter (hence, an asset) that contains servers. It’s also an organization that we maintain a contract with.
@b.stephenson (and anyone else for that matter) - Would you document this as both an asset and a supplier/third party?
We used Microsoft both in terms or Office365 and azure services and split this up as assets and as a Third Party. This meant I could associate the risks appropriately and create a mini compliance package for Microsoft.
When thinking about a remote datacenter I just approached it as if it was an on-prem DC in terms of documenting the assets and associated related assets. i.e azure datacentre(DC Asset 1) hosted X System(hardware Asset 2) running X Application (Software Asset 3) . This let me document the associated risks relating to the specific assets baring in mind they are hosted in the cloud i.e access control, backups, lack of monitoring etc.
For the third party ie Microsoft I then associated risks like data loss from attack against Microsoft, Risk of US Government tracking data, inability to fulfil DPA Requirements. For which I created a mini compliance package that I had to evidence the contractual terms and the Compliance Documents posted by Microsoft for their ISO and EU Model Clauses in their compliance centre on an annual basis.
From my processes I knew what systems they were using so I could say that a failure of Microsoft (Which happens quite a lot) would impact these business processes. However it would be good if when documenting the processes inside Eramba if you could select the applications, hardware etc that the business process utilises.
In essence whether its a SaaS PaaS or any other type of aaS I always split it out as both the asset and the third party providing the service as the risks are different and so too can the are stakeholders. But this is just they way i rationalised it in my own head.