1. Purpose
The Software License Register provides a centralized record of software, SaaS products, libraries, frameworks, development tools, cloud services, AI tools, and other licensed software used by the organization.
The register helps the organization:
- Identify software currently in use
- Establish licensing rights
- Track license ownership
- Monitor license terms and restrictions
- Prevent unauthorized software use
- Track renewal and expiry dates
- Identify open-source licensing obligations
- Identify software dependencies
- Support software license compliance
- Identify unsupported or unauthorized software
- Support procurement and offboarding
- Provide audit evidence
Core Principle
Identify → Verify License → Record Rights → Assign Owner → Monitor Use → Renew/Review → Remove When No Longer Required
2. When to Use
Maintain the register for software that is:
- Purchased
- Subscribed to
- Licensed
- Downloaded for organizational use
- Installed on organizational devices
- Used in production
- Used in development
- Used in cloud environments
- Integrated into applications
- Used as SaaS
- Used by employees or contractors
- Open-source
- Commercially licensed
- Provided by customers or suppliers
- Used for AI or machine-learning activities
The level of detail should be proportionate to the software’s risk and licensing requirements.
3. Register Information
| Field | Details |
|---|---|
| Register Name | Software License Register |
| Organization | |
| Register Owner | |
| IT Owner | |
| Security Owner | |
| Procurement Owner | |
| Legal/Compliance Owner | |
| Version | |
| Effective Date | |
| Last Review Date | |
| Next Review Date | |
| Approved By |
4. Master Software License Register
Maintain one primary record for each significant software product or license.
| License ID | Software | Version | Type | Provider | Owner | License Type | Status |
|---|---|---|---|---|---|---|---|
| LIC-001 | |||||||
| LIC-002 | |||||||
| LIC-003 |
Recommended Status
- Active
- Pending Approval
- Trial
- Expired
- Suspended
- Under Review
- Restricted
- Retired
- Prohibited
5. Software Identification
Identify the software used by the organization.
Business Software
☐ ERP
☐ CRM
☐ Accounting software
☐ HR software
☐ Project management
☐ Collaboration tools
☐ Document management
☐ Communication tools
Security Software
☐ EDR
☐ Antivirus
☐ Vulnerability scanner
☐ SIEM
☐ IAM
☐ Password manager
☐ Security testing tools
☐ Monitoring tools
Development Software
☐ IDE
☐ Source-code management
☐ CI/CD tools
☐ Build tools
☐ Testing tools
☐ Libraries
☐ Frameworks
☐ Package managers
☐ Container software
Cloud and SaaS
☐ SaaS applications
☐ Cloud platforms
☐ Cloud security services
☐ Cloud databases
☐ Cloud monitoring
☐ Cloud development tools
AI Software
☐ AI assistants
☐ Generative AI platforms
☐ AI APIs
☐ AI coding tools
☐ AI models
☐ AI datasets
☐ AI development platforms
6. License Information
For each software product, record:
| Field | Details |
|---|---|
| Software | |
| Provider | |
| Product | |
| Version | |
| License Type | |
| License Agreement | |
| Purchase Date | |
| Start Date | |
| Expiry Date | |
| Renewal Date | |
| License Owner | |
| Business Owner |
7. License Type
Classify the license.
☐ Per User
☐ Per Device
☐ Per Server
☐ Concurrent User
☐ Subscription
☐ Perpetual
☐ Consumption-Based
☐ API Usage
☐ Enterprise Agreement
☐ Trial
☐ Freeware
☐ Open Source
☐ Customer-Provided
☐ Other: __________________
8. License Rights
Document what the organization is actually permitted to do.
| License ID | Permitted Use | Users | Devices | Environments | Geographic Restriction | Other Restrictions |
|---|---|---|---|---|---|---|
Consider:
- Number of users
- Number of devices
- Number of installations
- Production use
- Development use
- Internal use
- Commercial use
- Redistribution
- Modification
- Integration
- API usage
- Geographic restrictions
- Affiliate/subsidiary use
9. License Quantity
Track purchased or permitted quantities.
| License ID | Purchased | Allocated | In Use | Available | Maximum Permitted | Utilization |
|---|---|---|---|---|---|---|
Example
If a software license permits 25 users:
Purchased: 25
Allocated: 20
In Use: 18
Available: 7
10. Software Assignment
Where licenses are assigned to individuals or systems:
| License ID | Software | User/System | Department | Assignment Date | Status |
|---|---|---|---|---|---|
11. Software Installation Register
For installed software, record:
| Software | Version | Device/System | Environment | Owner | Installation Date | Status |
|---|---|---|---|---|---|---|
| Development | ||||||
| Production |
Where centralized software inventory or endpoint management is available, integrate it with the license management process rather than duplicating information unnecessarily.
12. SaaS License Register
Record important SaaS services.
| SaaS ID | Service | Provider | Business Owner | Users | Data Classification | Subscription | Renewal |
|---|---|---|---|---|---|---|---|
| SaaS-001 | |||||||
| SaaS-002 |
Consider:
- Business purpose
- Users
- Information processed
- Supplier
- Contract
- Security assessment
- Data location
- Subprocessors
- Renewal
- Offboarding
13. Cloud Software and Services
For cloud services:
| Service | Provider | Account/Environment | Purpose | Owner | License/Billing Model | Criticality |
|---|---|---|---|---|---|---|
Examples:
- AWS services
- Cloud databases
- Monitoring platforms
- Security platforms
- Developer platforms
- Cloud-based testing tools
Cloud infrastructure services may not always operate under a traditional software license model; the register should capture the applicable subscription, service agreement, usage rights, or commercial terms.
14. Open-Source Software Register
Open-source software should be tracked where its licensing or security obligations are relevant.
| Component | Version | License | Application | Repository | Owner | License Review | Security Review |
|---|---|---|---|---|---|---|---|
Examples:
- Open-source libraries
- Frameworks
- Operating-system packages
- Container images
- Developer packages
- Infrastructure tools
15. Open-Source License Review
For relevant components:
☐ License identified
☐ License version identified
☐ Permitted use understood
☐ Attribution requirement identified
☐ Notice requirement identified
☐ Modification requirement identified
☐ Distribution requirement identified
☐ Source-code obligations assessed
☐ Copyleft implications considered
☐ Commercial use reviewed
☐ Customer distribution impact considered
☐ Legal review obtained where necessary
Not all open-source licenses impose the same obligations. The organization should review the actual applicable license terms.
16. Software Dependencies
For software products developed internally, maintain a dependency inventory or SBOM where appropriate.
| Application | Component | Version | License | Source | Criticality | Vulnerability Status |
|---|---|---|---|---|---|---|
Track:
- Direct dependencies
- Transitive dependencies
- Container images
- Operating-system packages
- Build dependencies
- Runtime dependencies
- Development dependencies
17. SBOM Reference
Where an SBOM exists:
| Application | SBOM Location | SBOM Date | Version | Owner | Review Status |
|---|---|---|---|---|---|
The Software License Register should reference the SBOM rather than duplicating every dependency when the SBOM already provides authoritative component-level information.
18. Commercial Software
For commercial software:
☐ License agreement available
☐ Purchase evidence available
☐ License quantity verified
☐ Users/devices verified
☐ Contract restrictions reviewed
☐ Renewal date recorded
☐ Support status checked
☐ Security requirements reviewed
☐ Owner assigned
19. Trial Software
Trial software must be controlled.
| Software | Provider | Trial Start | Trial End | Owner | Approved Purpose | Conversion/Removal |
|---|---|---|---|---|---|---|
At the end of the trial:
☐ License purchased
☐ Trial extended with authorization
☐ Software removed
☐ Account disabled
☐ Data exported/deleted as required
20. AI Software and AI Services
Record AI software and services where licensing, confidentiality, security, or contractual rights are relevant.
| AI Tool | Provider | Model/Service | Users | Data Used | Commercial Use | License/Terms Reviewed | Owner |
|---|---|---|---|---|---|---|---|
Review:
- Commercial-use rights
- Ownership of generated output
- Training/use of submitted data
- Data retention
- Model restrictions
- API terms
- Customer contractual restrictions
- Confidentiality requirements
- Copyright/licensing considerations
- Geographic restrictions
21. Customer-Provided Software
Where a customer provides software or licenses:
| Software | Customer | Purpose | License Owner | Permitted Users | Permitted Use | Return/Termination Requirement |
|---|---|---|---|---|---|---|
| Customer |
Customer-provided software should not automatically be treated as organizational software.
22. Supplier-Provided Software
Record software provided by suppliers or contractors.
| Software | Supplier | Purpose | Organization Use | License Owner | Contract | Security Review |
|---|---|---|---|---|---|---|
23. License Restrictions
Identify important restrictions.
| License ID | Restriction | Impact | Control | Owner |
|---|---|---|---|---|
| No redistribution | ||||
| User limit | ||||
| Commercial-use restriction | ||||
| Geographic restriction | ||||
| Source disclosure requirement |
24. Renewal Management
Track upcoming renewals.
| License ID | Software | Renewal Date | Renewal Notice | Cost/Commercial Review | Owner | Status |
|---|---|---|---|---|---|---|
Recommended status:
- Not Due
- Renewal Review
- Renewal Approved
- Renewal Pending
- Renewed
- Cancelled
25. Expired Licenses
When a license expires:
☐ Renewal completed
☐ License legitimately extended
☐ Software removed
☐ Users disabled
☐ Accounts disabled
☐ Production use stopped
☐ Data handling assessed
☐ Evidence retained
Expired software should not remain in production or business use unless continued use is authorized under valid licensing terms.
26. Unsupported Software
License compliance does not replace security management.
Identify software that is:
- End-of-life
- End-of-support
- No longer maintained
- Known vulnerable
- No longer required
- No longer licensed
| Software | Version | Support Status | Security Risk | Action | Owner | Due Date |
|---|---|---|---|---|---|---|
27. Software Risk Assessment
Assess important software for:
- Unauthorized use
- License violation
- Excess licensing
- Expired licensing
- Vendor dependency
- Security vulnerabilities
- Supply-chain compromise
- Unsupported versions
- Data exposure
- Customer contractual impact
- Business continuity impact
- Vendor lock-in
| Software | Risk | Likelihood | Impact | Risk Rating | Treatment |
|---|---|---|---|---|---|
28. License Compliance Review
Periodically verify:
☐ Software inventory matches actual use
☐ License quantities remain sufficient
☐ No unauthorized installations
☐ No unauthorized users
☐ License restrictions are understood
☐ Open-source obligations are addressed
☐ Expired licenses removed
☐ Trial software reviewed
☐ Unsupported software identified
☐ AI software reviewed
☐ Customer-provided software reviewed
☐ Supplier software reviewed
29. Software Discovery
Software may be identified through:
- Endpoint management
- Cloud inventory
- SaaS discovery
- Procurement records
- Finance records
- Application inventories
- Source repositories
- Package managers
- Container registries
- SBOMs
- Developer declarations
- Security scans
- Network monitoring
- Supplier assessments
Important
The license register should not depend solely on procurement records.
Software can enter an organization through:
Procurement + SaaS + Developers + Open Source + Cloud + Suppliers + Customer Projects
30. Unauthorized Software
If unauthorized software is identified:
- Record the software.
- Identify the user/system.
- Determine business purpose.
- Identify licensing requirements.
- Assess security risk.
- Determine whether it is permitted.
- Approve, license, replace, or remove it.
- Update the register.
- Record evidence.
31. License Violation
If a potential license violation is identified:
☐ Issue recorded
☐ Software/use identified
☐ License terms reviewed
☐ Scope determined
☐ Legal/compliance review performed where required
☐ Security impact assessed
☐ Customer impact assessed
☐ Corrective action defined
☐ Vendor contacted where appropriate
☐ Remediation completed
☐ Evidence retained
Do not assume that every license issue has the same legal or contractual consequence.
32. Software Offboarding
When software is no longer required:
☐ Business owner confirms removal
☐ Users identified
☐ Accounts disabled
☐ Access revoked
☐ Software removed where applicable
☐ API keys/tokens revoked
☐ Integrations removed
☐ Customer data handling assessed
☐ Data returned/deleted where required
☐ Subscription cancelled
☐ Auto-renewal disabled
☐ Register updated
33. Software Ownership
Every significant software license should have an accountable owner.
| Software | Business Owner | Technical Owner | Procurement Owner | Security Owner |
|---|---|---|---|---|
Ownership ensures that licenses do not remain unmanaged simply because they were originally purchased by another department.
34. Evidence Register
Maintain references to evidence rather than storing unnecessary sensitive information.
| License ID | Evidence | Location | Evidence Date | Reviewer |
|---|---|---|---|---|
| Purchase record | ||||
| License agreement | ||||
| Subscription record | ||||
| Vendor terms | ||||
| Open-source license | ||||
| SBOM |
Do not store passwords, API keys, access tokens, private keys, or other secrets as license evidence.
35. Exception Register
Where a software license or control requirement cannot be met:
| Exception ID | Software | Requirement | Reason | Risk | Compensating Control | Approver | Expiry |
|---|---|---|---|---|---|---|---|
Exceptions should be:
- Justified
- Risk assessed
- Approved
- Time limited where practical
- Periodically reviewed
36. License Review Schedule
Review frequency should be based on risk and licensing requirements.
| Software Category | Review Approach |
|---|---|
| Critical production software | Regular review |
| Security software | Regular review |
| Commercial SaaS | Before renewal and periodically |
| Open-source dependencies | Continuous/automated where practical |
| Developer tools | Periodic review |
| AI services | Before use and after material changes |
| Low-risk utilities | Periodic inventory review |
These are examples and should be aligned with the organization’s risk methodology.
37. License Register Summary
| Category | Total | Active | Expiring | Expired | Unlicensed/Unknown | Under Review |
|---|---|---|---|---|---|---|
| Commercial Software | ||||||
| SaaS | ||||||
| Open Source | ||||||
| Cloud Services | ||||||
| AI Software | ||||||
| Developer Tools | ||||||
| Security Tools | ||||||
| Customer Software | ||||||
| Supplier Software |
38. Outstanding Actions
| Action ID | License ID | Issue | Risk | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|---|---|
39. AWS SaaS Startup Example
A SaaS startup develops and operates an application using AWS.
Commercial SaaS
License ID: LIC-001
Software: Project Management SaaS
Type: Subscription
Users: 25
Owner: Operations
Renewal: Annual
Data: Internal/Confidential
Status: Active
Developer Tool
License ID: LIC-002
Software: Commercial IDE
Type: Per User
Users: 8
Owner: Engineering
Status: Active
Open-Source Component
License ID: OSS-001
Component: Application Framework
Version: Recorded in SBOM
License: Recorded from authoritative license file
Application: Production SaaS
Review: Completed
Security: Dependency monitoring enabled
AI Coding Tool
License ID: AI-001
Software: AI Coding Assistant
Users: Engineering Team
Data: Source code
Review: Security and licensing terms reviewed
Controls: Approved users, organizational account, restrictions on confidential/customer data
AWS
AWS services are recorded through the cloud/service inventory and commercial agreement rather than treating every AWS service as an individual traditional software license.
40. Startup-Friendly Implementation
A startup can begin with five categories:
1. Commercial Software
Record:
- Product
- Provider
- Users
- License type
- Renewal
- Owner
2. SaaS
Record:
- Application
- Business purpose
- Users
- Data
- Supplier
- Renewal
3. Open Source
Record:
- Component
- Version
- License
- Application
- Security status
Use an SBOM or dependency management system as the detailed source where appropriate.
4. Developer and AI Tools
Record:
- Tool
- Users
- Data accessed
- License/terms
- Approval
- Owner
5. Critical Production Software
Record:
- Application
- Dependencies
- License
- Business owner
- Technical owner
- Security status
- Support status
41. Common Mistakes
Avoid:
- Maintaining only a list of purchased software.
- Ignoring SaaS subscriptions.
- Ignoring developer-installed software.
- Ignoring open-source components.
- Ignoring transitive dependencies.
- Failing to track license restrictions.
- Allowing expired licenses to remain active.
- Tracking renewal dates but not actual usage.
- Treating free software as having no licensing obligations.
- Assuming open-source means unrestricted.
- Ignoring AI software terms.
- Failing to identify customer-provided software.
- Failing to remove software after contract termination.
- Keeping license evidence in personal email accounts.
- Storing passwords or API keys in the license register.
42. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Intellectual Property Register | Records software/IP ownership |
| Intellectual Property Protection Policy | Defines IP protection requirements |
| Software Asset Register | Identifies software assets |
| Open Source Software Policy | Defines open-source requirements |
| Software License Compliance Procedure | Defines license compliance process |
| SBOM | Provides component-level dependency information |
| Vulnerability Management Procedure | Addresses software vulnerabilities |
| Supplier Security Assessment | Assesses software/service providers |
| Cloud Services Register | Records cloud services |
| SaaS Register | Records SaaS applications |
| Change Management | Controls significant software changes |
| Access Control Policy | Controls licensed software access |
| Procurement Procedure | Controls software acquisition |
| Offboarding Procedure | Removes software and access |
| Risk Register | Tracks significant software risks |
43. ISO/IEC 27001 Connection
Software license management supports the organization’s risk-based protection of information, systems, technology, intellectual property, and supplier relationships.
It can support areas such as:
- Asset management
- Information classification
- Access control
- Intellectual property protection
- Supplier security
- Secure development
- Vulnerability management
- Configuration management
- Software installation and use
- Change management
- Information deletion
- Cloud and SaaS security
- Technology supply-chain security
The Software License Register is not itself a universally mandatory ISO/IEC 27001 document.
The organization should determine the appropriate level of license management based on:
- Information-security risk
- Business requirements
- Software licensing obligations
- Contractual requirements
- Customer commitments
- Legal requirements
- Technology environment
44. Audit Evidence
Examples include:
- Software License Register
- Purchase records
- License agreements
- Subscription agreements
- Vendor contracts
- Renewal records
- Software inventory
- SaaS inventory
- Open-source inventory
- SBOM
- License review records
- Dependency reports
- Software installation records
- Access records
- Procurement approvals
- Security reviews
- AI tool assessments
- License exception records
- Software removal records
- Offboarding evidence
- Corrective action records
45. Final Software License Audit Trail
For every significant software product, the organization should be able to demonstrate:
What software are we using?
Who provides it?
Who owns the license?
What license do we have?
What are we permitted to do?
How many users or installations are permitted?
How many are actually being used?
When does the license expire?
What restrictions apply?
Is the software supported and secure?
Are open-source obligations understood?
Are dependencies identified?
Is the software approved?
Who is accountable for it?
What happens when the software is no longer required?
46. Final Principle
Discover → Identify → Verify the License → Record Rights → Assign Ownership → Approve → Monitor Usage → Review Security & Licensing → Renew or Remove → Retain Evidence
A Software License Register should not be treated as merely a procurement spreadsheet. It should connect software usage, licensing rights, security risk, ownership, dependencies, contractual obligations, renewals, and offboarding into one defensible record.