1. Purpose
The purpose of this procedure is to ensure that information and technology assets are properly managed throughout their lifecycle — from acquisition or creation through use, maintenance, change, transfer, and retirement or disposal.
Effective asset lifecycle management helps the organization:
- Know what assets it owns, uses, or depends on.
- Assign appropriate ownership and responsibility.
- Protect assets according to their business importance and information classification.
- Manage security risks throughout the asset lifecycle.
- Prevent unauthorized access to retired or disposed assets.
- Maintain accurate asset and information inventories.
- Support ISO 27001 audit and compliance requirements.
Core principle:
An asset should be identified, owned, classified, protected, monitored, reviewed, and securely retired throughout its lifecycle.
2. Scope
This procedure applies to information and assets that support the organization’s business and information security objectives, including:
- Information and business data
- Applications and software
- Source code and repositories
- Cloud infrastructure
- Servers and databases
- Laptops, desktops, and mobile devices
- Network equipment
- SaaS applications
- User accounts and identities
- Encryption keys and secrets
- Security and monitoring systems
- Backup systems and media
- Business documentation
- Physical assets
- Third-party assets and services
- Customer-related systems and information
The procedure applies to employees, contractors, consultants, third parties, and other personnel responsible for organizational assets.
3. Asset Lifecycle
A typical asset lifecycle is:
Identify → Acquire/Create → Approve → Assign Owner → Classify → Configure/Deploy → Use → Maintain → Monitor → Review → Change/Transfer → Retire → Secure Disposal → Update Records
Not every asset will require every stage. The lifecycle should be adapted to the type and risk of the asset.
4. Asset Lifecycle Management Principles
The organization should follow these principles:
4.1 Asset Identification
Important assets should be identified and recorded in the appropriate inventory or register.
4.2 Ownership
Important assets should have a clearly identified owner.
The owner is accountable for the asset but does not necessarily perform all technical or operational activities.
4.3 Classification
Information and associated assets should be classified according to their sensitivity, business value, and security requirements.
4.4 Risk-Based Protection
Protection should be proportionate to the asset’s:
- Confidentiality requirements
- Integrity requirements
- Availability requirements
- Business criticality
- Legal/regulatory requirements
- Contractual requirements
- Threat exposure
4.5 Least Privilege
Access to assets should be limited to authorized users based on business need.
4.6 Lifecycle Control
Security requirements should apply throughout the asset lifecycle, not only when the asset is initially deployed.
4.7 Secure Retirement
Assets should be securely decommissioned and disposed of when no longer required.
4.8 Accurate Records
Asset registers should be updated when assets are acquired, changed, transferred, retired, or disposed of.
5. Asset Lifecycle Process
Step 1 — Identify the Asset
Before an asset is introduced into the organization, determine:
- What is the asset?
- What business process does it support?
- Who will use it?
- What information does it process?
- Is customer, employee, financial, confidential, or sensitive information involved?
- Is it internally owned or provided by a third party?
- Is it business-critical?
Example:
A startup introduces a new customer-support SaaS platform that stores customer information and support tickets.
The application should be identified and recorded before production use.
6. Step 2 — Acquisition or Creation
Assets may be:
- Purchased
- Developed internally
- Provisioned in the cloud
- Subscribed to as SaaS
- Provided by a supplier
- Transferred from another organization or business unit
Before acquisition or creation, the organization should consider:
- Business requirement
- Security requirements
- Risk
- Data classification
- Privacy requirements
- Legal/regulatory requirements
- Supplier security
- Contractual requirements
- Availability and recovery requirements
- Exit and disposal requirements
For significant assets, security and risk review should occur before approval.
7. Step 3 — Approval
Assets should be appropriately approved before being introduced into the organization’s environment.
Approval may include:
- Business owner
- IT/technical owner
- Security
- Procurement
- Privacy/legal
- Risk owner
The level of approval should be proportionate to the asset’s risk.
Example
A developer requesting a new AWS production account may require formal approval because it could contain production systems and customer information.
A low-risk productivity tool may follow a simpler approval process.
8. Step 4 — Assign Ownership
Each important asset should have an identified owner.
The owner should understand:
- Business purpose
- Criticality
- Information processed
- Security requirements
- Access requirements
- Risk
- Retention requirements
- Lifecycle requirements
- Retirement requirements
Example
| Asset | Owner | Technical Custodian |
|---|---|---|
| Customer Database | CTO | Database Administrator |
| Source Code Repository | Engineering Lead | DevOps |
| Employee Records | HR Manager | HR Platform Administrator |
| AWS Production Account | CTO | Cloud/DevOps Lead |
| Corporate Laptops | IT Manager | IT Support |
| Security Logs | Security Lead | SOC/IT Team |
9. Step 5 — Classification and Security Requirements
Before an asset becomes operational, its information and security requirements should be determined.
Consider:
- Confidentiality
- Integrity
- Availability
- Personal data
- Customer data
- Regulatory requirements
- Contractual requirements
- Business criticality
Example classification levels may include:
| Classification | Example |
|---|---|
| Public | Public website content |
| Internal | Internal procedures |
| Confidential | Customer database |
| Restricted | Production credentials or encryption keys |
These classification levels are organizational examples and should be defined according to the organization’s own classification scheme.
10. Step 6 — Secure Configuration and Deployment
Assets should be securely configured before being placed into operational use.
Depending on the asset, this may include:
- Access control
- MFA
- Encryption
- Secure configuration
- Network restrictions
- Logging
- Monitoring
- Backup
- Vulnerability management
- Endpoint protection
- Secrets management
- Security testing
- Patch management
AWS Example
For an AWS production database, security configuration may include:
- Restricted network access
- IAM-based access
- MFA for privileged users
- Encryption using KMS
- CloudTrail logging
- Monitoring
- Backup configuration
- Security group restrictions
- Vulnerability management
- Defined owner
11. Step 7 — Operational Use
During normal operation, assets should be:
- Used only for authorized purposes.
- Accessed only by authorized personnel.
- Protected according to their classification.
- Monitored where appropriate.
- Maintained according to business and security requirements.
- Included in applicable backup and recovery processes.
- Subject to applicable security reviews.
Users should not install, modify, transfer, or dispose of organizational assets outside approved processes.
12. Step 8 — Maintenance and Security Updates
Assets should be maintained throughout their operational life.
Maintenance may include:
- Security patches
- Software updates
- Firmware updates
- Vulnerability remediation
- Configuration reviews
- Access reviews
- Certificate renewal
- License renewal
- Backup verification
- Security monitoring
- Performance and availability monitoring
Security updates should be prioritized according to risk and organizational requirements.
13. Step 9 — Monitoring and Review
Assets should be periodically reviewed to confirm that they remain:
- Required
- Properly owned
- Correctly classified
- Securely configured
- Appropriately accessed
- Adequately protected
- Supported
- Compliant with applicable requirements
Review frequency should be risk-based.
For example:
| Asset Type | Example Review |
|---|---|
| Critical production systems | Monthly/quarterly |
| Privileged accounts | Periodic access review |
| SaaS applications | Periodic security review |
| Laptops | Periodic inventory reconciliation |
| Cloud resources | Continuous/periodic reconciliation |
| Low-risk assets | Annual review |
These frequencies are examples, not universal ISO requirements.
14. Step 10 — Changes and Transfers
Changes to important assets should follow the organization’s change management process where applicable.
Examples include:
- Change of owner
- Change of location
- Change of classification
- Major configuration change
- Migration
- System upgrade
- Transfer to another employee
- Transfer between departments
- Cloud account restructuring
- Supplier change
The asset register should be updated after the change.
Example
An employee leaves the organization and their laptop is transferred to another employee.
The organization should:
- Recover the device.
- Remove the former user’s access.
- Securely reset/reconfigure the device.
- Assign the device to the new user.
- Update the asset register.
- Confirm required security controls.
15. Step 11 — End-of-Life Assessment
When an asset is no longer required, the owner should determine whether it should be:
- Retained
- Archived
- Replaced
- Migrated
- Returned to supplier
- Transferred
- Decommissioned
- Destroyed
The decision should consider:
- Business requirements
- Legal requirements
- Regulatory retention
- Contractual requirements
- Data retention
- Security risk
- Cost
- Availability of replacement systems
16. Step 12 — Secure Decommissioning
Before an asset is decommissioned, access and dependencies should be identified.
The organization should consider:
- User accounts
- Service accounts
- API credentials
- Encryption keys
- Certificates
- Integrations
- DNS records
- Network connections
- Backups
- Logs
- Data retention
- Third-party dependencies
Example
Before retiring an AWS application:
- Confirm business approval.
- Identify customer data.
- Confirm migration/retention requirements.
- Disable application access.
- Remove unnecessary IAM access.
- Revoke credentials and secrets.
- Remove infrastructure.
- Handle backups according to retention requirements.
- Confirm data deletion where required.
- Update the cloud asset inventory.
- Record the retirement evidence.
17. Step 13 — Secure Disposal
Where an asset contains information, disposal should prevent unauthorized recovery or disclosure.
Depending on the asset, this may include:
- Secure deletion
- Cryptographic erasure
- Device reset
- Media destruction
- Physical destruction
- Certified disposal through an approved supplier
- Secure return to supplier
For third-party disposal, evidence such as a disposal certificate may be retained where appropriate.
18. Step 14 — Update Asset Records
After retirement or disposal, the relevant register should be updated.
Typical fields include:
- Asset status
- Retirement date
- Disposal date
- Disposal method
- Disposal/return reference
- Responsible person
- Evidence
- Data deletion confirmation
- Supplier confirmation, where applicable
Example lifecycle status values:
Planned → Active → Under Maintenance → Transferred → Retired → Disposed
19. AWS SaaS Startup Example
Consider a SaaS company operating its production environment in AWS.
Asset
AWS Production RDS Customer Database
Lifecycle
1. Create
Database is provisioned for the SaaS application.
2. Register
The database is added to the Cloud Asset Inventory.
3. Owner
CTO is assigned as asset owner and Cloud/DevOps Lead as technical custodian.
4. Classify
Customer information is classified according to the organization’s classification scheme.
5. Secure
Encryption, IAM access controls, network restrictions, logging and backups are configured.
6. Operate
The database is monitored and maintained.
7. Review
Access, configuration, vulnerabilities, backup status and ownership are periodically reviewed.
8. Change
Database architecture is changed as the application scales.
The change follows applicable change-management requirements.
9. Retire
The database is no longer required after migration to a new environment.
10. Dispose
Required data is retained or migrated, unnecessary data is securely deleted, credentials are revoked, and the old database is decommissioned.
11. Update
The Cloud Asset Inventory and related records are updated with retirement evidence.
20. Asset Lifecycle Records
Depending on the organization’s environment, records may include:
| Record | Purpose |
|---|---|
| Information & Asset Inventory | Identify assets |
| Asset Ownership Register | Assign responsibility |
| Asset Classification Record | Determine protection requirements |
| Cloud Asset Inventory | Track cloud resources |
| SaaS Application Register | Track third-party SaaS |
| Change Records | Track significant changes |
| Access Reviews | Verify authorized access |
| Maintenance Records | Demonstrate maintenance |
| Disposal Records | Demonstrate secure disposal |
| Supplier Records | Track third-party assets |
| Backup Records | Demonstrate recoverability |
| Risk Register | Track asset-related risks |
21. Asset Lifecycle and Risk Management
Asset lifecycle management should be connected to the organization’s risk management process.
The relationship can be:
Asset → Owner → Classification → Threat → Risk → Control → Evidence → Review → Change/Retirement
Example
Customer database
↓
CTO as owner
↓
Confidential classification
↓
Unauthorized access threat
↓
High/Critical risk
↓
IAM + MFA + encryption + monitoring + access review
↓
Audit evidence
↓
Periodic review
↓
Secure retirement
This prevents the asset register from becoming a simple list of IT equipment.
22. Roles and Responsibilities
Top Management
- Provide resources.
- Establish expectations for asset protection.
- Review significant asset-related risks.
Asset Owner
- Understand business importance.
- Ensure appropriate classification.
- Define security requirements.
- Approve access where applicable.
- Review asset status.
- Ensure appropriate lifecycle management.
Technical Custodian
- Maintain technical configuration.
- Apply security controls.
- Perform maintenance.
- Monitor the asset.
- Support secure decommissioning.
IT / Cloud / Engineering
- Provision and configure assets.
- Apply technical security controls.
- Maintain systems.
- Manage technical changes.
Security / ISMS Manager
- Define lifecycle requirements.
- Monitor compliance with the procedure.
- Support risk assessment.
- Coordinate security reviews.
- Maintain relevant ISMS records.
Procurement
- Support secure acquisition.
- Ensure applicable supplier requirements are addressed.
- Support supplier return/disposal requirements.
Employees and Contractors
- Use assets appropriately.
- Protect assigned assets.
- Report loss, damage, or suspected compromise.
- Return organizational assets when required.
23. Asset Disposal and Employee Offboarding
Asset lifecycle management should integrate with the employee joiner-mover-leaver process.
When an employee leaves:
Offboarding Trigger → Identify Assigned Assets → Recover Assets → Disable Access → Transfer Ownership → Secure/Reconfigure → Update Inventory → Retain/Dispose
Examples:
- Laptop
- Mobile phone
- Security token
- Access cards
- SaaS accounts
- Cloud credentials
- Cryptographic devices
- Company documents
- Removable media
The organization should ensure that returning a physical asset does not automatically mean that associated digital access has been removed.
24. Third-Party and SaaS Assets
Third-party assets should also be considered.
For a SaaS application, lifecycle management may include:
Business Need → Security/Privacy Review → Supplier Assessment → Approval → Contract → Configuration → User Access → Monitoring → Periodic Review → Renewal → Exit → Data Return/Deletion
Before terminating a SaaS service, consider:
- Data export
- Data retention
- Data deletion
- User access removal
- API integrations
- SSO configuration
- Tokens/API keys
- Backup copies
- Contractual requirements
- Evidence of deletion
25. Asset Lifecycle Exceptions
If an asset cannot follow the standard lifecycle process, the exception should be documented and risk assessed.
Examples:
- Emergency acquisition
- Legacy system
- Unsupported technology
- Supplier-controlled asset
- Temporary infrastructure
- Emergency production environment
The exception record should include:
- Asset
- Reason
- Risk
- Compensating controls
- Risk owner
- Approval
- Expiry/review date
Exceptions should not become permanent alternatives to normal lifecycle management.
26. Audit Evidence
An auditor may sample assets and trace them through their lifecycle.
Possible evidence includes:
- Asset inventory
- Ownership records
- Classification records
- Purchase/procurement records
- Approval records
- Configuration records
- Access reviews
- Change tickets
- Maintenance records
- Vulnerability scans
- Security monitoring
- Backup records
- Supplier records
- Retirement approvals
- Data deletion records
- Disposal certificates
- Updated inventory
Audit Test Example
An auditor selects an AWS production database and checks:
Inventory → Owner → Classification → Risk → Access → Security Configuration → Monitoring → Backup → Review → Change History → Retirement Process
This demonstrates whether lifecycle management operates in practice rather than merely whether a procedure exists.
27. Common Mistakes
Mistake 1 — Treating asset management as an IT inventory only
Information, SaaS applications, cloud services, source code, identities, and business services can also be important assets.
Mistake 2 — No asset owner
An asset without an accountable owner can easily become unmanaged.
Mistake 3 — Only tracking assets at acquisition
Security requirements continue throughout the asset lifecycle.
Mistake 4 — Ignoring cloud resources
Unused or unknown cloud resources can create security and cost risks.
Mistake 5 — Forgetting SaaS applications
Shadow IT can result in organizational information being stored in unapproved applications.
Mistake 6 — Poor retirement controls
Deleting an application does not necessarily delete its backups, credentials, integrations, or retained data.
Mistake 7 — Not updating the inventory
An asset register becomes unreliable when transfers, changes and retirements are not recorded.
Mistake 8 — Treating all assets identically
Protection should be proportionate to business value, information sensitivity and risk.
28. Startup-Friendly Implementation
A startup does not necessarily need a sophisticated asset-management platform.
A controlled spreadsheet, GRC platform, ITSM system, or combination of existing cloud tools may be sufficient initially.
At minimum, maintain:
Information & Asset Inventory
Track:
- Asset
- Type
- Owner
- Location/platform
- Classification
- Criticality
- Related risk
- Status
- Last review
Cloud Asset Inventory
Track:
- AWS/Azure/GCP account
- Resource
- Environment
- Owner
- Region
- Data processed
- Internet exposure
- Criticality
- Status
SaaS Application Register
Track:
- Application
- Provider
- Business purpose
- Owner
- Data processed
- Criticality
- Supplier risk
- Contract
- Renewal
- Status
Disposal/Retirement Record
Track:
- Asset
- Owner
- Retirement date
- Reason
- Data handling
- Disposal method
- Evidence
- Approver
29. Relationship with Other ISMS Documents
Asset Lifecycle Management should connect with:
Information & Asset Inventory
→ What assets exist?
Asset Ownership Register
→ Who is accountable?
Asset Classification Procedure
→ How should the asset be protected?
Risk Assessment
→ What could happen to the asset?
Risk Treatment Plan
→ What protection is required?
Statement of Applicability
→ Which necessary controls apply?
Access Control Policy
→ Who can access the asset?
Change Management
→ How are significant changes controlled?
Backup & Recovery
→ How is availability/data recovery maintained?
Supplier Security
→ How are third-party assets managed?
Incident Management
→ What happens if the asset is compromised?
Secure Disposal Procedure
→ How is the asset securely retired?
The overall relationship is:
Inventory → Ownership → Classification → Risk → Treatment → Protection → Monitoring → Review → Retirement → Disposal → Evidence
30. Quick Audit Checklist
| Check | Yes/No | Evidence |
|---|---|---|
| Is the asset identified? | ||
| Is an owner assigned? | ||
| Is the asset classified? | ||
| Is its business criticality understood? | ||
| Are security requirements defined? | ||
| Was acquisition/creation approved? | ||
| Is access appropriately controlled? | ||
| Is the asset securely configured? | ||
| Is maintenance performed? | ||
| Is the asset monitored where appropriate? | ||
| Is the asset periodically reviewed? | ||
| Are changes controlled? | ||
| Are ownership transfers recorded? | ||
| Is end-of-life assessed? | ||
| Is data securely retained/deleted? | ||
| Is the asset securely decommissioned? | ||
| Is disposal evidence retained where applicable? | ||
| Is the inventory updated? | ||
| Are related risks updated when required? |
31. Final Principle
Asset management is not simply knowing what assets the organization has.
Effective lifecycle management means:
Identify → Own → Classify → Assess → Protect → Use → Maintain → Monitor → Review → Change → Retire → Dispose → Verify
For an ISO 27001 ISMS, the objective is to ensure that important information and assets remain known, owned, protected, and appropriately managed from creation to secure retirement.