A Practical ISO/IEC 27001:2022 Guide for Startups and SaaS Companies
1. Purpose
The Information and Asset Inventory is used to identify, record, classify, and manage the information and assets that support an organization’s business operations and Information Security Management System (ISMS).
It helps the organization understand:
- What information and assets it owns, uses, stores, processes, or manages.
- Where information is stored and processed.
- Who is responsible for each asset or information set.
- How sensitive or important the information is.
- Which security risks and controls apply.
- Which assets depend on cloud providers, SaaS platforms, and third-party services.
The inventory should reflect the organization’s actual environment rather than a generic list copied from another company.
2. Scope of the Inventory
The inventory may include the following categories, depending on the organization’s business and ISMS scope.
| Category | Examples |
|---|---|
| Information and data | Customer records, employee records, financial data, contracts |
| Applications and software | SaaS applications, ERP, CRM, HRMS, ticketing systems |
| Cloud infrastructure | AWS accounts, EC2, RDS, S3, Azure resources |
| Hardware | Laptops, desktops, servers, network devices |
| Source code and development assets | Git repositories, CI/CD pipelines, build artifacts |
| Identity and access assets | Identity providers, privileged accounts, authentication systems |
| Security assets | SIEM, EDR, vulnerability scanners, security logs |
| Documentation | Policies, procedures, architecture diagrams, audit reports |
| Business services | Customer support, payment processing, production hosting |
| Third-party services | Cloud providers, payment gateways, outsourced IT services |
| Physical assets and facilities | Offices, server rooms, removable media |
| Backup and recovery assets | Database backups, recovery copies, backup platforms |
Important: Record assets and information that are relevant to the ISMS and its risks. An organization does not need to include every trivial item in the same level of detail.
3. Information and Asset Inventory Register
Use the following fields as the main inventory template.
| Field | What to record |
|---|---|
| Asset ID | Unique identifier, such as AST-001 |
| Asset / Information Name | Name of the asset or information set |
| Asset Category | Information, software, hardware, cloud, service, documentation, etc. |
| Description | Business purpose and use |
| Business Process | Process supported by the asset |
| Asset / Information Owner | Person accountable for the asset or information |
| Custodian / Technical Owner | Team or person responsible for operating or maintaining it |
| Location | Office, AWS region, SaaS platform, repository, or other location |
| System / Platform | Application, cloud account, database, or service where it resides |
| Information Classification | Public, Internal, Confidential, or Restricted, according to the organization’s classification scheme |
| Confidentiality | Required protection against unauthorized disclosure |
| Integrity | Required protection against unauthorized alteration or destruction |
| Availability | Required availability and recovery capability |
| Criticality | Business importance of the asset |
| Personal / Sensitive Data | Whether personal, financial, customer, or other sensitive data is involved |
| External / Third-Party Dependency | Provider or external party supporting the asset |
| Access Restrictions | Roles, groups, or permissions permitted to access it |
| Backup / Recovery Requirement | Applicable backup, restoration, or recovery arrangements |
| Related Risk ID | Reference to the relevant risk assessment or risk register |
| Related Control / Requirement | Applicable security control, policy, or requirement |
| Lifecycle Status | Active, Under Development, Retired, or Disposed |
| Last Reviewed | Date the record was last checked |
| Evidence / Reference | Link to system records, configuration, or supporting documentation |
Not every field needs to be mandatory for every asset category. For example, a physical laptop and a customer database will require different technical details.
4. Sample Inventory for an AWS-Based SaaS Startup
The following entries are illustrative examples. Replace them with the organization’s actual assets, owners, locations, and configurations.
| Asset ID | Asset / Information | Category | Owner | Classification | Criticality |
|---|---|---|---|---|---|
| AST-001 | Customer database | Information / Database | CTO / Data Owner | Confidential | Critical |
| AST-002 | Production application | Application | Engineering Lead | Internal | Critical |
| AST-003 | AWS production account | Cloud Infrastructure | Cloud Lead | Confidential | Critical |
| AST-004 | Customer documents in S3 | Information / Cloud Storage | Data Owner | Confidential | High |
| AST-005 | Source code repository | Development Asset | Engineering Lead | Confidential | High |
| AST-006 | Employee records | Information | HR Manager | Restricted | High |
| AST-007 | Corporate laptops | Hardware | IT Manager | Internal | Medium |
| AST-008 | Identity provider | Identity and Access | IT / Security Lead | Confidential | Critical |
| AST-009 | Application and security logs | Security Information | Security Lead | Confidential | High |
| AST-010 | Backup and recovery platform | Backup / Recovery | Cloud Lead | Confidential | Critical |
| AST-011 | Customer support platform | SaaS Application | Support Lead | Confidential | High |
| AST-012 | Payment gateway integration | Third-Party Service | Finance / Technical Owner | Confidential | High |
Classification labels and criticality ratings should follow the organization’s approved methodology. Criticality is not necessarily the same as information classification.
5. Information Classification
The organization should define and consistently apply a classification scheme appropriate to its information and business risks.
An illustrative scheme is:
| Classification | Description | Examples |
|---|---|---|
| Public | Approved for public disclosure | Published website content, public brochures |
| Internal | Intended for internal business use | Internal process documents, routine meeting notes |
| Confidential | Disclosure could cause business, customer, or contractual harm | Customer records, source code, business contracts |
| Restricted | Highly sensitive information requiring particularly strong safeguards | Authentication secrets, highly sensitive personal information, critical security credentials |
The organization should define handling rules for each level, including access, storage, transmission, sharing, retention, and disposal.
Note: These labels are examples, not mandatory ISO 27001 classification names.
6. Identify Information Owners and Asset Owners
Each important asset or information set should have a clearly assigned owner.
| Role | Responsibility |
|---|---|
| Information / Asset Owner | Determines business importance, classification, access needs, and acceptable use |
| Technical Custodian | Maintains the asset, technical configuration, and operational safeguards |
| Security / ISMS Manager | Coordinates inventory maintenance and checks alignment with security requirements |
| Business Process Owner | Confirms business use, dependencies, and operational requirements |
| Risk Owner | Evaluates and manages risks associated with the asset |
| Employees and Contractors | Use assets according to approved policies and report changes or security concerns |
In a small startup, one individual may perform multiple roles. Responsibilities should still be clearly defined.
7. Determine Information Security Requirements
For important information and assets, identify the protection required for confidentiality, integrity, and availability.
Example:
Asset: Customer database hosted on AWS RDS
- Confidentiality: Only approved application identities and authorized administrators can access customer records.
- Integrity: Database changes are restricted, authenticated, logged where appropriate, and recoverable.
- Availability: Backups, monitoring, and tested recovery procedures support the required service availability.
- Access: Privileged access requires strong authentication and approval.
- Encryption: Encryption is applied in transit and at rest where required by risk, contracts, and organizational policy.
- Monitoring: Relevant database and administrative activities are logged and reviewed.
- Risk linkage: Unauthorized access, data exposure, data corruption, and service disruption are assessed in the risk register.
The exact safeguards should be determined by the organization’s risk assessment, applicable requirements, and business needs.
8. Link the Inventory to Risk Assessment
The inventory provides inputs to risk assessment. It does not replace the risk register.
For each important asset or information set, consider:
- What information or business service does it support?
- What could go wrong?
- What threats and vulnerabilities could affect it?
- What would the impact be if confidentiality, integrity, or availability were compromised?
- What safeguards already exist?
- What additional risk treatment is required?
- Who owns the risk, and what evidence demonstrates the safeguards are working?
Example:
| Asset | Risk Scenario | Potential Impact | Example Treatment |
|---|---|---|---|
| Customer database | Unauthorized access | Customer data exposure, contractual consequences | Restrict access, enforce authentication, monitor activity |
| Source code repository | Repository compromise | Intellectual property theft, malicious code changes | Strong authentication, least privilege, protected branches |
| Backup platform | Backup deletion or corruption | Inability to recover data | Restrict deletion permissions, monitor backup jobs, test restoration |
| Employee laptops | Device loss or malware | Data exposure, business disruption | Device encryption, endpoint protection, access controls |
Create links to the relevant risk IDs so that the inventory and risk register remain connected.
9. Review and Maintenance Procedure
The inventory should be maintained throughout the asset lifecycle.
Recommended workflow:
Identify → Register → Assign Owner → Classify → Assess Requirements → Link Risks → Apply Controls → Review → Update → Retire or Dispose
Update the inventory when:
- A new application, cloud service, database, or major asset is introduced.
- A new type of information is collected or processed.
- An application or asset changes ownership or purpose.
- Infrastructure, architecture, or hosting arrangements change.
- A supplier or third-party service is added or removed.
- Significant security incidents or risk assessments reveal missing assets.
- An asset is decommissioned, replaced, or disposed of.
A quarterly review can be a useful starting point for a startup, with more frequent reviews for rapidly changing or critical environments. The appropriate frequency should reflect the organization’s risks and rate of change.
10. Evidence for an ISO 27001 Audit
An auditor may sample the inventory and compare it with actual business and technical environments.
Potential evidence includes:
- The approved information and asset inventory.
- Asset ownership and classification records.
- Cloud resource and account inventories.
- Application and SaaS service lists.
- Hardware or endpoint management records.
- Data flow diagrams and system architecture diagrams.
- Access permissions and asset-related configuration records.
- Risk register entries linked to important assets.
- Backup, recovery, and disposal records where relevant.
- Inventory review history and records of updates.
A spreadsheet is acceptable as a practical starting point if it is accurate, maintained, appropriately protected, and supported by operational evidence. A dedicated asset management tool is not automatically required.
11. Common Mistakes to Avoid
- Recording only laptops and physical equipment while ignoring information and cloud services.
- Listing assets without assigning accountable owners.
- Using classification labels without defining how information must be handled.
- Treating the inventory as a one-time exercise.
- Copying a generic asset list without confirming actual applicability.
- Recording a security control as implemented without verifying evidence.
- Failing to track assets managed by suppliers or cloud providers.
- Confusing the asset inventory with the risk register or Statement of Applicability.
12. Final Review Checklist
- Important information and assets within the ISMS scope have been identified.
- Relevant applications, cloud resources, information repositories, and third-party services are included.
- Important assets and information have accountable owners.
- Locations, platforms, and key dependencies are documented.
- Classification and handling requirements have been assigned where appropriate.
- Confidentiality, integrity, and availability needs have been considered.
- Relevant assets are linked to risk assessments and security requirements.
- The inventory reflects the current environment.
- Review and change-management responsibilities are defined.
- Supporting evidence is available for audit sampling.
- Retired assets and disposed information are handled through appropriate processes.
13. Relationship with ISO/IEC 27001:2022
The inventory supports the organization’s risk-based ISMS and provides useful inputs for asset-related security controls.
Relevant references include:
- Clause 6.1.2 — Information security risk assessment: The inventory helps identify information and assets that may be affected by information security risks.
- Clause 6.1.3 — Information security risk treatment: Asset and information details help determine appropriate risk treatment.
- Annex A 5.9 — Inventory of information and other associated assets: Addresses maintaining an inventory of information and associated assets, including ownership.
- Annex A 5.12 — Classification of information: Supports classification according to the organization’s information security needs.
- Annex A 5.13 — Labelling of information: Supports appropriate information labelling where applicable.
- Annex A 5.11 — Return of assets: Relevant to the return of organizational assets when employment, contracts, or other relationships end.
The inventory is one input to the ISMS; it does not by itself demonstrate that all related controls are effectively implemented.
Conclusion
An effective Information and Asset Inventory answers five fundamental questions:
What do we have? Where is it? Who owns it? How important is it? What security protection does it need?
For a startup, the goal is not to create the largest possible spreadsheet. It is to maintain a reliable view of important information, supporting assets, ownership, dependencies, and security requirements—and use that view to make informed risk and control decisions.