Whether you are pursuing an ISO 27001 certification or a SOC 2 report, a robust asset inventory is going to be key to addressing compliance requirements and help you understand the environment your assets live in.
But a frequent question we hear is, “How do we build an effective asset inventory that truly reflects a cloud-based SaaS company?”
Assets are those things that ensure the operation of your system/platform and the supporting processes. Common examples are laptops, contracts, and servers. High-growth tech companies tend to have assets that change on a daily basis, like containers and auto-scaled servers that are hard to reflect on an asset inventory.
Combining best practices and our own lessons we’ve learned in the field, here is how to build a Master Asset Inventory for a SaaS company:
Design and Manage Your Master Asset Inventory
An effective asset inventory will help your organization understand the various assets in use and the risks & opportunities these introduce into the environment. This starts with the identification of the assets in-scope for your organization, including intangible assets. A useful foundation for building your asset inventory is within the ISO 27001 Annex A.8 – Asset Management controls. This is where recurring themes across frameworks, such as defining asset owners, data classification, and asset handling are laid out. These form the basis for the asset inventory recommendations below.
A notable difference in this approach is the categorization of assets into “buckets” and a unified approach regarding assets within those categories. This should minimize a lot of the granular labeling and management of assets you may be accustomed to in an asset inventory. This is where you start developing a Master Asset Inventory.
Please note: the examples below feature an asset inventory implemented using the Phalanx GRC Inventories module, designed specifically for creating and managing a variety of inventories. This can be implemented using a spreadsheet or a variety of other formats.
Develop the Master Asset Inventory
The first step is to establish the asset types or “buckets”, based on the technology stack of your organization and how those assets are used.
Examples of Asset Types or “Buckets”
- User Endpoints (Laptops & Workstations)
- Production Application Servers (AWS EC2)
- Development Environments
- Containers (GCP Kubernetes)
- Databases (AWS RDS)
- Physical Co-located Servers
- Source Code
- Corporate Documents (Physical or Digital)
- Removable Media
These will be unique to your organization; however, once those categories are established, you can start organizing them into a Master Asset Inventory. Keep in mind that you may want to group asset buckets based on functionality (e.g., Production Servers vs. Development Servers) even if the asset themselves are the same type (such as AWS EC2 instances or Google Kubernetes Engines).
The next step is identifying the applicable categories you want for the asset “buckets”. Some recommended categories are:
Granular Inventory
This is where your granular asset inventory lives. For endpoints, an example would be the mobile device management (MDM) dashboard, so feel free to call out where that detailed inventory resides. An easy way of doing this is inserting the dashboard hyperlink or language such as “See MDM Tool Dashboard for details”.
Asset Owner
This is where you establish the ownership for the asset “buckets”. I recommend establishing departmental ownership, and individual ownership where appropriate. For user endpoints (mobile devices and laptops), where ownership is at the individual level, feel free to include language such as “See Granular Inventory for details”.
Acceptable Use
Reference the Acceptable Use Policy and/or procedures for this asset type. This will serve as evidence that each asset type has rules established around their acceptable use, as well as identify any assets which may not have these and allow for remediation. This reference can be simply to the policy and/or policy section or a hyperlink to the policy repository location.
Label(s)
Labeling assets in alignment with the data classification, or sensitivity, is key to any asset inventory. Ensuring assets are classified appropriately is a topic unto itself, however some things to consider include under labels is the data classification (e.g., Restricted, Confidential, Public), sensitive data types (e.g., Personally Identifiable Information – PII, and Personal Health Information – PHI) and environment type (e.g., Production, Development, Test).
Depending on the number of labels you wish to use, it may make sense to break the classification level into a separate category for clarity.
Handling Procedure
Reference the data handling policy and/or procedures for the asset type. This is especially important for assets that contain production data, or support production infrastructure. This reference can be made to the policy and/or policy section, or a hyperlink to the policy repository location.
Identified Risk(s)
While not normally a requirement, it might be necessary to note risks associated with a certain asset type simply due to the type of the asset, or the data contained within. A good practice is calling those out within the Master Asset Inventory, where appropriate, to ensure that risks are a consideration when evaluating the various asset types.
Associated Vendors(s)
While also not a common requirement, it is a good practice to list vendors associated with the asset type. This factors into vendor risk management, as well as understanding the key vendors that support your inventory.
Here is what this all looks like in practice, within the Phalanx Inventories Module:
Conclusion
A Master Asset Inventory should eliminate a lot of the common pitfalls, such as assets without defined owners or data classifications, when managing an asset inventory. While you will still need to understand and manage your assets within the various systems, you will find this simplifies your management processes.
Leave A Comment