1. Purpose

The SaaS Application Register is used to identify, document, assess, and manage third-party Software-as-a-Service (SaaS) applications used by the organization.

SaaS applications may process sensitive business information, customer information, employee information, credentials, source code, financial information, or security data. The organization therefore needs visibility into:

• Which SaaS applications are being used.
• Why each application is used.
• Who owns the application.
• What information it processes.
• Where the information is stored or processed.
• Who can access it.
• Whether the application is business-critical.
• What security and privacy requirements apply.
• Which supplier provides the service.
• What contractual protections exist.
• How the application is monitored and reviewed.
• When the application should be retired.

The register supports the organization’s ISMS, supplier security management, risk assessment, access control, information classification, privacy management, and business continuity activities.

---

2. Scope

The register should cover SaaS applications that are:

• Officially procured by the organization.
• Approved for business use.
• Used to process organizational information.
• Used to process customer information.
• Used by employees or contractors for business activities.
• Integrated with corporate systems.
• Connected to organizational identity providers.
• Used to support critical business processes.

Examples include:

• Microsoft 365 / Google Workspace
• Slack / Microsoft Teams
• GitHub / GitLab
• Jira / ServiceNow
• Salesforce / HubSpot
• HR and payroll platforms
• Accounting platforms
• Customer support platforms
• Cloud security platforms
• Project management platforms
• Marketing platforms
• CRM systems
• File-sharing platforms
• E-signature platforms
• AI-based SaaS applications
• Security and compliance platforms

Personal consumer applications that are not approved for business use should generally be managed through the organization’s acceptable-use or shadow-IT process rather than simply being added as approved SaaS applications.

---

3. SaaS Application Management Principles

3.1 Know What Is Being Used

The organization should maintain visibility over important SaaS applications.

3.2 Assign an Internal Owner

Every important SaaS application should have an accountable internal owner.

3.3 Understand the Data

Before using a SaaS application, determine what organizational or customer information will be processed.

3.4 Assess Supplier Risk

Security, privacy, contractual, availability, and business risks should be considered based on the nature and criticality of the service.

3.5 Control Access

Access should be based on business need and appropriate authorization.

3.6 Review Periodically

Applications, users, permissions, supplier security, and business requirements should be reviewed periodically.

3.7 Manage the Full Lifecycle

SaaS applications should follow:

Request → Assess → Approve → Configure → Use → Review → Renew → Retire

---

4. SaaS Application Register — Main Template

Field	Description
SaaS ID	Unique application identifier
Application Name	Name of SaaS application
Provider / Supplier	SaaS provider
Application URL	Official application URL
Business Purpose	Why the organization uses it
Business Process	Process supported
Application Owner	Internal accountable owner
Technical Owner	IT/security/technical custodian
Department	Primary business department
User Population	Employees, contractors, customers, etc.
Number of Users	Approximate active users
Information Processed	Type of information handled
Information Classification	Public, Internal, Confidential, Restricted
Personal Data	Whether personal data is processed
Customer Data	Whether customer information is processed
Criticality	Critical, High, Medium, Low
Integration	SSO, API, SCIM, other integrations
Authentication	SSO/MFA/password/etc.
Privileged Access	Administrative access details
Supplier Risk	Low, Medium, High, Critical
Security Assessment	Status and date
Privacy Assessment	Status and date
Contract	Contract status
DPA	Data Processing Agreement status where applicable
Security Agreement	Security requirements / contractual terms
Data Location	Hosting or processing location where known
Retention	Data retention requirements
Backup / Recovery	Business continuity considerations
Incident Notification	Supplier notification requirement
Exit / Deletion	Data return/deletion arrangements
Renewal Date	Contract/subscription renewal
Last Review	Last application review
Next Review	Next planned review
Status	Approved, Conditional, Under Review, Retired
Related Risk ID	Relevant risk reference
Evidence	Supporting documentation

---

5. Sample SaaS Application Register

The following is an illustrative example for a technology/SaaS startup.

ID	SaaS Application	Purpose	Owner	Data	Classification	Criticality	Status
SaaS-001	Microsoft 365	Email & collaboration	IT Manager	Business/Employee	Confidential	Critical	Approved
SaaS-002	GitHub Enterprise	Source code	CTO	Source Code	Confidential	Critical	Approved
SaaS-003	Jira	Project management	Engineering Lead	Project Data	Internal	High	Approved
SaaS-004	Salesforce	CRM	Sales Head	Customer Data	Confidential	High	Approved
SaaS-005	HR Platform	HR management	HR Manager	Employee Data	Restricted	High	Approved
SaaS-006	Zendesk	Customer support	Support Lead	Customer Data	Confidential	High	Approved
SaaS-007	DocuSign	Electronic signatures	Legal/Operations	Contracts	Confidential	High	Approved
SaaS-008	Slack	Communication	IT Manager	Business Information	Internal/Confidential	High	Approved
SaaS-009	Security Platform	Security monitoring	Security Lead	Security Data	Confidential	High	Approved
SaaS-010	AI Productivity Tool	Business productivity	Business Owner	Business Information	Risk-based	Medium	Conditional

Actual applications, providers, data types, and classifications should be determined from the organization’s environment.

---

6. SaaS Application Ownership

Each important SaaS application should have an internal owner.

The owner is accountable for:

• Business justification.
• Application approval.
• Data classification.
• User access requirements.
• Supplier assessment.
• Security requirements.
• Contractual requirements.
• Periodic review.
• Renewal or termination.
• Data retention and deletion.
• Business continuity considerations.

The SaaS provider operates the service, but the organization retains responsibility for deciding whether the application is appropriate for its business use.

---

7. SaaS Technical Custodian

The technical custodian supports the operational and security configuration of the application.

Responsibilities may include:

• SSO configuration.
• MFA configuration.
• User provisioning.
• SCIM configuration.
• Administrative roles.
• API integrations.
• Security settings.
• Logging.
• Monitoring.
• Backup/export configuration.
• Integration management.
• Offboarding.

Example:

Application: GitHub Enterprise

Application Owner: CTO

Technical Custodian: DevOps Lead

Business Users: Engineering

The CTO remains accountable for the application, while DevOps manages the technical configuration.

---

8. SaaS Business Criticality

The organization should determine how important each SaaS application is to business operations.

Criticality	Example
Critical	Loss could significantly interrupt core business or customer services
High	Loss could materially affect important business operations
Medium	Loss would cause manageable disruption
Low	Loss has limited operational impact

Criticality should consider:

• Business dependency.
• Number of users.
• Customer impact.
• Data sensitivity.
• Revenue dependency.
• Operational dependency.
• Availability requirements.
• Recovery alternatives.

---

9. Information Processed by SaaS Applications

Before approving a SaaS application, identify the information it will process.

Examples:

SaaS	Information
CRM	Customer and prospect information
HR platform	Employee information
GitHub	Source code and technical information
Email	Business and customer communications
Accounting platform	Financial information
Support platform	Customer support records
E-signature platform	Contracts and personal information
AI SaaS	Depends on information submitted by users

The information should be classified according to the organization’s classification framework.

---

10. SaaS Security Assessment

The level of supplier assessment should be proportionate to risk.

Possible assessment areas include:

Organization and Governance

• Security policies.
• Security governance.
• Security certifications.
• Independent assurance reports.

Access Control

• MFA.
• SSO.
• RBAC.
• Privileged access.
• User lifecycle management.

Data Protection

• Encryption.
• Data segregation.
• Data retention.
• Data deletion.
• Data export.

Infrastructure Security

• Network security.
• Vulnerability management.
• Secure development.
• Security monitoring.

Incident Management

• Incident response.
• Security incident notification.
• Customer communication.
• Investigation support.

Availability

• Business continuity.
• Disaster recovery.
• Service availability.
• Backup and recovery.

Privacy

• Data processing.
• Subprocessors.
• Data location.
• Data subject requirements.
• Data deletion.

Not every SaaS application requires the same depth of assessment.

---

11. SaaS Supplier Risk Classification

A simple risk model may be used.

Supplier Risk	Typical Characteristics
Low	Limited business impact and no sensitive information
Medium	Internal business information or moderate operational dependency
High	Sensitive information, customer data, or important business dependency
Critical	Critical business service, highly sensitive information, or significant customer/operational dependency

Risk classification should be based on the organization’s approved supplier risk methodology.

---

12. SaaS Approval Process

A practical approval process is:

Business Need → Data Assessment → Risk Assessment → Security/Privacy Review → Supplier Assessment → Contract Review → Approval → Configuration → User Access → Periodic Review

Before approving a high-risk SaaS application, consider:

• What data will be uploaded?
• Is customer data involved?
• Is personal information involved?
• Is source code involved?
• Is the application business-critical?
• Does it support SSO/MFA?
• Who will have administrative access?
• Where is data processed?
• What contractual protections exist?
• How are incidents reported?
• What happens when the contract ends?

---

13. Shadow IT

Employees may sometimes adopt SaaS applications without formal approval.

Examples:

• Unapproved file-sharing platforms.
• Personal AI tools.
• Personal cloud storage.
• Unapproved project-management applications.
• Unapproved collaboration tools.
• Browser-based data-processing services.

The organization should have a process to identify and manage unauthorized SaaS use.

Shadow IT Process

Detect → Identify Application → Identify Users → Determine Data → Assess Risk → Approve / Restrict / Remove → Update Register

The objective should be risk reduction rather than simply maintaining a list of prohibited applications.

---

14. SaaS Access Management

Access should follow the organization’s access-control process.

Joiner

New employee → Business approval → Account creation → Appropriate access

Mover

Role change → Access review → Modify permissions → Remove unnecessary access

Leaver

Employee departure → Disable account → Revoke sessions/tokens → Transfer business data → Confirm closure

For important SaaS applications, SSO and automated provisioning/deprovisioning can reduce access-management risks.

---

15. SaaS Administrative Access

Administrative access should receive additional protection.

Recommended controls may include:

• MFA.
• SSO.
• Least privilege.
• Separate administrative accounts where appropriate.
• Limited number of administrators.
• Access approval.
• Periodic access review.
• Logging.
• Monitoring.
• Emergency access procedures.

Example:

GitHub Organization Administrator

→ CTO/Engineering approval
→ MFA required
→ Limited administrators
→ Periodic access review
→ Administrative activity logged where available

---

16. SaaS Integrations and API Access

The register should identify significant integrations.

Examples:

• SaaS ↔ Microsoft 365
• SaaS ↔ HR platform
• SaaS ↔ CRM
• SaaS ↔ AWS
• SaaS ↔ GitHub
• SaaS ↔ Identity Provider

Record:

• Integration purpose.
• Systems involved.
• Data exchanged.
• Authentication method.
• API credentials/service accounts.
• Owner.
• Security requirements.
• Risk.

API keys and secrets should not be stored in the SaaS Application Register.

---

17. SaaS Data Location

Where relevant, record:

• Hosting country/region.
• Processing locations.
• Backup locations.
• Subprocessor locations.
• Data transfer arrangements.

This can be particularly important for:

• Customer information.
• Employee information.
• Personal data.
• Financial information.
• Regulated information.

If the provider’s exact location is unknown, record the limitation and identify the evidence or supplier documentation used.

---

18. Contractual Requirements

Important SaaS contracts should be reviewed for relevant security requirements.

Consider:

• Confidentiality.
• Data protection.
• Security requirements.
• Incident notification.
• Breach notification.
• Availability commitments.
• Service levels.
• Subprocessors.
• Data location.
• Data retention.
• Data deletion.
• Audit or assurance information.
• Business continuity.
• Termination assistance.

The register should record the status of important contractual requirements rather than reproducing the entire contract.

---

19. Security Assurance Evidence

Depending on the application’s risk, evidence may include:

• ISO/IEC 27001 certificate.
• SOC 2 report.
• Independent penetration test summary.
• Security questionnaire.
• Security architecture information.
• Privacy documentation.
• Data Processing Agreement.
• Business continuity information.
• Incident response information.
• Supplier security assessment.

The presence of a certification or report does not automatically mean the SaaS application is suitable for the organization’s specific use case. The organization should assess the evidence in context.

---

20. SaaS Privacy Assessment

Where personal data is processed, assess:

• What personal data is processed?
• Why is it processed?
• Who is the data controller/processor in the relevant context?
• Where is the data processed?
• Who are the subprocessors?
• How long is data retained?
• How can data be deleted?
• What security measures are provided?
• What happens after contract termination?

Applicable privacy requirements should be determined based on the organization’s jurisdictions, data subjects, services, and contracts.

---

21. SaaS Business Continuity

For critical SaaS applications, consider:

• Service availability.
• Provider outage procedures.
• Data export capability.
• Backup arrangements.
• Alternative processes.
• Recovery procedures.
• Provider disaster recovery information.
• Business continuity dependencies.

Example:

Critical SaaS CRM unavailable

Potential response:

→ Activate business continuity procedure
→ Use available exported customer information if appropriate
→ Communicate internally
→ Monitor supplier status
→ Restore normal operations
→ Review incident and supplier performance

---

22. SaaS Renewal Review

Before renewing a significant SaaS application, review:

• Business requirement.
• Current users.
• Current access permissions.
• Data processed.
• Security assessment.
• Privacy requirements.
• Supplier performance.
• Incidents.
• Contract changes.
• Pricing and licensing.
• Business continuity.
• Alternative solutions.
• Data retention and deletion requirements.

This helps prevent unnecessary SaaS subscriptions and reduces unused or unmanaged applications.

---

23. SaaS Application Retirement

When a SaaS application is no longer required:

Business Approval → Data Export/Retention Assessment → Access Removal → Integration Removal → Contract Termination → Data Deletion/Return → Verification → Register Update

Verify:

• User accounts are disabled.
• API integrations are removed.
• Tokens/API credentials are revoked.
• Data is returned or deleted as required.
• Backups are addressed.
• Supplier termination is documented.
• Evidence is retained.

---

24. SaaS Risk Register Linkage

Important SaaS applications should be linked to relevant risks.

Example:

SaaS: Customer Support Platform

Risk: Unauthorized disclosure of customer information.

Threat: Compromised user account.

Existing Controls:

• SSO.
• MFA.
• RBAC.
• Access reviews.
• Logging.
• Supplier security assessment.

Risk Owner: Support Manager / appropriate designated risk owner.

Related SaaS ID: SaaS-006

This provides traceability:

SaaS → Information → Risk → Control → Evidence

---

25. SaaS Application Review

During periodic review, confirm:

• Is the application still required?
• Is the owner still correct?
• Is the supplier still approved?
• Has the data processed changed?
• Has classification changed?
• Are users still appropriate?
• Are privileged users still appropriate?
• Are integrations still required?
• Has the supplier changed its security posture?
• Have contracts changed?
• Are privacy requirements still satisfied?
• Has the risk changed?
• Is the application still business-critical?
• Is renewal appropriate?

---

26. Suggested Review Frequency

Review frequency should be risk-based.

SaaS Category	Example Review
Critical SaaS	Quarterly or risk-based
High-risk SaaS	At least annually or when significant changes occur
Sensitive-data SaaS	At least annually or risk-based
Medium-risk SaaS	Annually
Low-risk SaaS	Periodically
New SaaS application	Before approval
Major supplier change	Event-driven
Contract renewal	Before renewal

These are example frequencies and should be adapted to organizational risk.

---

27. Audit Evidence

Potential audit evidence includes:

• SaaS Application Register.
• SaaS approval records.
• Supplier assessments.
• Security questionnaires.
• SOC 2/ISO 27001 reports where applicable.
• Contracts.
• Data Processing Agreements.
• Access reviews.
• SSO/MFA configuration.
• User provisioning/deprovisioning records.
• Supplier risk assessments.
• Privacy assessments.
• Incident records.
• Business continuity assessments.
• Renewal reviews.
• SaaS retirement records.

An auditor may select a SaaS application and trace:

Application → Owner → Data → Classification → Supplier → Risk → Security Requirements → Access → Evidence

---

28. Common Mistakes

Mistake 1 — Only Listing Paid Applications

Free or trial SaaS applications can also create security risks if organizational information is entered into them.

Mistake 2 — No Business Owner

IT should not automatically become the owner of every SaaS application.

Mistake 3 — Ignoring AI SaaS

AI applications may process sensitive business or customer information and should be evaluated according to their use and risk.

Mistake 4 — No Data Assessment

Knowing the SaaS name is not enough. The organization should understand what information is processed.

Mistake 5 — Relying Only on Vendor Certifications

A vendor’s ISO 27001 certificate or SOC 2 report is useful evidence, but the organization should still assess whether the service meets its specific requirements.

Mistake 6 — No Offboarding

SaaS applications should have a defined retirement process, including access removal and data handling.

Mistake 7 — Ignoring Integrations

API connections and SSO integrations can create additional security dependencies.

---

29. Startup-Friendly Implementation

A startup can implement SaaS governance without creating a complicated procurement process.

Minimum Process

1. Identify

Create a list of business SaaS applications.

2. Assign Owners

Assign one accountable owner to each important application.

3. Identify Data

Record what information is processed.

4. Classify

Apply the organization’s information classification.

5. Assess Risk

Consider data sensitivity, business dependency, integrations, and supplier risk.

6. Review Security

Check appropriate security assurance and controls.

7. Approve

Obtain appropriate business/security approval.

8. Control Access

Use SSO, MFA, RBAC, and periodic access reviews where appropriate.

9. Review

Review important SaaS applications periodically.

10. Retire

Remove access and manage data appropriately when the application is no longer required.

A spreadsheet or GRC platform is sufficient for many early-stage organizations. A dedicated SaaS Management Platform (SMP/SAM) can be considered as the number of applications, users, and integrations grows.

---

30. Minimum SaaS Application Register

For a small startup, the following fields provide a practical starting point:

SaaS ID	Application	Provider	Purpose	Owner	Data	Classification	Criticality	Users	MFA/SSO	Supplier Risk	Renewal	Status
SaaS-001	CRM	Provider	Sales	Sales Head	Customer Data	Confidential	High	15	SSO/MFA	High	Date	Approved
SaaS-002	Code Repository	Provider	Development	CTO	Source Code	Confidential	Critical	20	SSO/MFA	High	Date	Approved
SaaS-003	HR Platform	Provider	HR	HR Manager	Employee Data	Restricted	High	50	SSO/MFA	High	Date	Approved
SaaS-004	Collaboration	Provider	Communication	IT Manager	Business Data	Internal	High	50	SSO/MFA	Medium	Date	Approved

---

31. Relationship With Other ISMS Documents

The SaaS Application Register should connect with:

SaaS Application Register
↓
Identifies third-party applications

Information & Asset Inventory
↓
Identifies information and associated assets

Asset Ownership Register
↓
Assigns accountable owners

Asset Classification Procedure
↓
Determines information protection requirements

Supplier Security Assessment
↓
Evaluates supplier security

Risk Register
↓
Records SaaS-related risks

Access Control
↓
Controls users and privileged access

Privacy / Data Protection Assessment
↓
Evaluates personal data processing

Contract / DPA Review
↓
Establishes contractual requirements

Business Continuity
↓
Addresses critical SaaS dependency

Incident Management
↓
Addresses SaaS security incidents

Internal Audit
↓
Verifies implementation and effectiveness

---

32. Quick Audit Checklist

• Important SaaS applications have been identified.
• SaaS owners are assigned.
• Technical custodians are identified where appropriate.
• Business purpose is documented.
• Information processed is identified.
• Information classification is recorded.
• Business criticality is assessed.
• Supplier risk is assessed.
• Security requirements are reviewed.
• Privacy requirements are assessed where applicable.
• Contracts and relevant agreements are reviewed.
• SSO/MFA is implemented where appropriate.
• Administrative access is controlled.
• User access is periodically reviewed.
• Important integrations are documented.
• Renewal reviews are performed.
• SaaS retirement and data deletion requirements are defined.
• Shadow IT is addressed.
• Relevant risks are linked.
• Supporting evidence is available for audit.

---

33. Final Principle

A good SaaS Application Register should answer:

What SaaS applications do we use?
Why do we use them?
Who owns them?
What information do they process?
How sensitive is that information?
Who can access the application?
How secure is the supplier?
What happens if the service becomes unavailable?
What happens when we stop using it?

The practical lifecycle is:

Discover → Assess → Approve → Assign Owner → Configure Securely → Control Access → Monitor → Review → Renew or Retire