Asset Management Policy

Document Control

1. Purpose and Scope

This policy defines the requirements for identifying, tracking and managing the assets owned, managed or controlled by Hamurlabs through their lifecycle, from acquisition to disposal. It covers physical assets (laptops, workstations, mobile devices, office network equipment), virtual and cloud assets (Google Cloud projects, virtual machines, databases, storage, source code repositories, corporate SaaS accounts), and information assets. The Information Security Manager (ISM) facilitates and maintains this policy and ensures all personnel have reviewed it.

2. Asset Inventory

Hamurlabs maintains a designated asset inventory, owned by the engineering organisation. The inventory is the authoritative record of significant assets and must be kept up to date by the responsible owners and verified by the ISM at least quarterly. Items may be excluded only if they carry very low replacement cost and pose little or no risk to business operations or compliance status. Cloud-native inventory sources (e.g. the cloud provider’s asset listing, the identity provider’s user and device lists, repository listings) may be used as supporting records, provided the designated inventory identifies where each asset class is tracked.

Each inventory record must include:

• Unique identifier or name of the asset;
• Description, type (physical / virtual / software / data) and, where relevant, make/model, technical specifications, licence details and versions;
• Purpose of the asset and its role in supporting critical business processes or legal/regulatory requirements, if applicable;
• Owner responsible for the asset;
• Location or environment (office, remote, cloud project);
• Classification per the Data Classification Policy (HL-ISMS-POL-04), where the asset contains or handles information;
• Status (active / retired) and relevant lifecycle dates.

3. Asset Ownership

Every asset is assigned an owner when created or transferred to Hamurlabs. The owner is responsible for the asset over its entire lifecycle or until a new owner is assigned, and must: ensure the asset is inventoried; ensure it is appropriately classified and protected; define and periodically review access restrictions in line with the User Access Control Policy (HL-ISMS-POL-03); and ensure proper handling when the asset is retired, deleted or destroyed.

4. System Hardening

• Manufacturer hardening guides and, where practicable, Center for Internet Security (CIS) benchmarks are used for configuration guidance.
• Vendor-supplied defaults (usernames, passwords, common settings) must be changed before deployment.
• Insecure and unnecessary communication protocols and services are disabled.
• Local passwords, when required, are randomly generated and stored in the approved password manager.
• Current security patches are installed; patching is prioritised by criticality and performed during off-peak hours where disruption is possible.
• Malware protection and logging are enabled in accordance with the Network Security Policy (HL-ISMS-POL-02).
• Multi-factor authentication is used wherever the platform supports it.
• A current architecture/network diagram and configuration standards are maintained and available to authorised engineering personnel.

5. Endpoint Security

• Company-issued endpoints must run supported operating systems with automatic updates, full-disk encryption, screen lock and endpoint protection enabled.
• Anti-malware tooling is configured to update automatically, run scans and alert on detection.
• The use of removable media is restricted to authorised personnel with a business need; contents of reusable media being retired must be made unrecoverable, and cryptographic protection must be used for confidential data on removable media per the Encryption Policy (HL-ISMS-POL-07).
• Company-owned devices are subject to a complete data wipe when necessary (e.g. infection, repurposing, return); the wipe is carried out by the responsible engineering/IT personnel and logged.

6. Capacity Management

Capacity requirements of production systems are identified in line with business criticality. Monitoring and alerting are applied to ensure availability and to indicate problems as they occur; projections of future capacity account for new business and observed trends. Capacity is managed by scaling cloud resources, deleting obsolete data, decommissioning unused environments, and optimising application logic and database queries.

7. Return of Assets upon Termination

The offboarding process includes the return of all physical and electronic assets issued to the person, in accordance with the employment terms and this policy. Where personal equipment was used with authorisation, all Hamurlabs information must be transferred to Hamurlabs and securely erased from the equipment. Account deactivation is handled per the User Access Control Policy.

8. Asset Retirement and Disposal

The asset owner determines when an asset is no longer needed. Before retiring any asset that stores data, the retention requirements of the Data Destruction and Retention Policy (HL-ISMS-POL-10) must be reviewed; data subject to retention must be migrated to an appropriate destination and verified before deletion from the original asset. Secure disposal of media containing confidential information is proportional to sensitivity: erasure with verified deletion, physical destruction (shredding/incineration) via an appropriate disposal service, or cryptographic erasure of encrypted volumes. Each disposal is logged to maintain an audit trail.

9. Related Documents

• HL-ISMS-POL-03 User Access Control Policy
• HL-ISMS-POL-04 Data Classification Policy
• HL-ISMS-POL-07 Encryption Policy
• HL-ISMS-POL-10 Data Destruction and Retention Policy