1. Purpose
The SaaS / Shadow IT Register provides a centralized record of SaaS applications and other externally hosted services used, requested, discovered, or suspected within the organization.
The purpose is to identify SaaS usage that may exist outside the organization’s formal procurement, security, IT, or compliance processes and determine whether the service:
- Is formally approved.
- Is being used without authorization.
- Processes organizational information.
- Processes customer or personal data.
- Provides access to business systems.
- Creates security or compliance risks.
- Requires supplier due diligence.
- Requires a contract or DPA.
- Should be approved, restricted, replaced, or discontinued.
The objective is visibility and risk-based governance, not simply preventing employees from using SaaS applications.
2. Scope
The register may include:
- Business SaaS applications
- Productivity applications
- Collaboration tools
- File-sharing platforms
- AI tools
- Generative AI applications
- Developer platforms
- Project-management tools
- Marketing platforms
- HR platforms
- Finance applications
- Customer-support platforms
- CRM systems
- Security platforms
- Analytics platforms
- Browser-based applications
- Free SaaS services
- Freemium services
- Trial accounts
- Applications purchased using corporate cards
- Applications accessed using corporate email
- Applications discovered through technical monitoring
It should include both:
Approved SaaS
and
Unapproved or Unknown SaaS
3. What Is Shadow IT?
Shadow IT refers to technology, software, cloud services, SaaS applications, accounts, or integrations used for organizational activities without appropriate visibility, approval, or governance.
Examples include:
- An employee using a personal AI tool to summarize confidential documents.
- A developer creating a free account on an online testing platform.
- A marketing employee uploading customer lists to an unapproved analytics tool.
- A team using a free project-management application without security review.
- An employee storing company files in a personal cloud-storage account.
- A developer connecting an unapproved SaaS application to a corporate GitHub repository.
The fact that a service was not formally approved does not automatically mean that it is malicious or prohibited.
The organization should first understand the use case, information involved, access, and risk.
4. Core Governance Principle
The register should follow:
Discover → Identify → Understand Use → Identify Information → Assess Access → Assess Supplier → Assess Risk → Approve/Restrict/Remove → Monitor → Review
The central questions are:
What SaaS is being used?
Who is using it?
Why is it being used?
What information is being shared?
What systems can it access?
Has it been assessed and approved?
5. Register Ownership
| Role | Responsibility |
|---|---|
| IT / Cloud Owner | Maintains SaaS visibility |
| Security Team | Performs security assessment |
| Procurement | Reviews commercial relationship |
| Privacy Team | Reviews personal-data processing |
| Business Owner | Confirms business need |
| Risk/Compliance | Assesses compliance implications |
| Finance | Identifies purchases/subscriptions |
| Internal Audit | Reviews governance effectiveness |
| Employees | Report new SaaS usage where required |
A single organization should designate an accountable owner for maintaining the register.
6. SaaS / Shadow IT Register
The following fields can be used as the primary register.
| Field | Description |
|---|---|
| SaaS ID | Unique identifier |
| Application Name | SaaS/application name |
| Provider | Vendor/company |
| Website | Official service URL |
| Category | AI/CRM/HR/Developer/etc. |
| Business Owner | Responsible business owner |
| Technical Owner | IT/security owner |
| Department | Using department |
| Users | Number/user group |
| Business Purpose | Why it is used |
| Discovery Source | Procurement/SSO/Finance/Employee/etc. |
| Discovery Date | Date identified |
| Status | Approved/Under Review/Unapproved/Restricted/Retired |
| Shadow IT | Yes/No |
| Contract | Yes/No |
| Procurement Approved | Yes/No |
| Security Assessment | Completed/Pending/Not Required |
| Privacy Assessment | Completed/Pending/N/A |
| Risk Assessment | Completed/Pending |
| Risk Rating | Low/Medium/High/Critical |
| Information Processed | Data handled |
| Classification | Public/Internal/Confidential/Restricted |
| Personal Data | Yes/No |
| Customer Data | Yes/No |
| Sensitive Data | Yes/No |
| Source Code | Yes/No |
| Credentials/Secrets | Yes/No |
| Production Access | Yes/No |
| API Access | Yes/No |
| SSO | Yes/No |
| MFA | Yes/No |
| Admin Access | Yes/No |
| Data Location | Country/Region |
| Subprocessors | Yes/No/Unknown |
| Security Assurance | SOC 2/ISO/etc. |
| DPA Required | Yes/No |
| DPA Status | Executed/Pending/N/A |
| Supplier Criticality | Low/Medium/High/Critical |
| Decision | Approve/Restrict/Replace/Remove |
| Action Owner | Responsible person |
| Due Date | Target date |
| Last Review | Date |
| Next Review | Date |
| Evidence | Evidence reference |
| Remarks | Additional information |
7. SaaS Identification
For every discovered SaaS application, capture:
- Application name
- Provider
- Service URL
- Service category
- Business purpose
- Department
- Business owner
- Number of users
- Discovery source
Avoid relying only on employee declarations.
SaaS discovery may come from multiple sources.
8. SaaS Discovery Sources
Potential discovery sources include:
Identity and SSO
- SSO applications
- Identity-provider logs
- OAuth applications
- Enterprise application registrations
Network
- DNS logs
- Secure web gateway
- Proxy logs
- Firewall logs
- CASB
- DNS security tools
Finance
- Corporate card transactions
- Purchase records
- Expense reports
- Subscription payments
Procurement
- Vendor records
- Purchase orders
- Contracts
Endpoint
- Browser extensions
- Installed applications
- Endpoint telemetry
Cloud
- API integrations
- OAuth connections
- Cloud marketplace subscriptions
Employees
- Self-reporting
- IT requests
- Security reporting channels
Using multiple discovery sources improves visibility.
9. Shadow IT Classification
Each discovered service should be classified.
Example:
| Status | Meaning |
|---|---|
| Approved | Formally reviewed and approved |
| Approved With Conditions | Approved subject to defined controls |
| Under Review | Assessment in progress |
| Unknown | Usage identified but owner/use not confirmed |
| Unapproved | Used without required approval |
| Restricted | Usage limited to defined conditions |
| Prohibited | Organization has determined it must not be used |
| Retiring | Approved for removal |
| Retired | No longer used |
10. Business Purpose Review
For each SaaS application determine:
- Why is it being used?
- Which department uses it?
- Which business process depends on it?
- Is there an approved alternative?
- Is it necessary?
- Who owns the relationship?
- What would happen if the service became unavailable?
A service should not be approved simply because employees already use it.
11. Information Assessment
Identify what information is entered, uploaded, stored, transmitted, or generated.
Examples:
- Public information
- Internal information
- Confidential information
- Customer information
- Personal data
- Financial information
- Source code
- Security information
- Credentials
- Business strategy
- Intellectual property
- Employee information
The risk of a SaaS application depends significantly on the information it handles.
12. Information Classification
Determine the highest relevant classification.
Example:
| Data | Classification |
|---|---|
| Public marketing material | Public |
| Internal project information | Internal |
| Customer support tickets | Confidential |
| Production credentials | Restricted |
| Source code | Confidential/Restricted |
The organization’s actual information-classification scheme should be used.
13. Customer Data Review
Determine whether the SaaS application processes:
- Customer names
- Email addresses
- Support tickets
- Customer documents
- Customer credentials
- Usage information
- Customer transaction information
- Other customer-controlled information
If customer information is involved, review applicable contractual, security, and privacy requirements.
14. Personal Data Review
Determine whether the SaaS provider processes personal data.
Consider:
- Employees
- Customers
- Prospects
- Suppliers
- Contractors
- Other individuals
Where personal data is processed, determine whether privacy review, DPA, transfer assessment, retention controls, or other requirements apply.
15. Access Assessment
Determine what access the SaaS application receives.
Examples:
- No corporate integration
- Corporate email only
- SSO
- Read-only access
- File access
- Git repository access
- Database access
- API access
- Administrative access
- Production access
The more systems and information a SaaS application can access, the greater the need for appropriate assessment and controls.
16. OAuth and Application Integrations
Review connected applications and OAuth permissions.
Examples:
- Google Workspace
- Microsoft 365
- GitHub
- Slack
- Jira
- CRM
- Cloud platforms
Determine:
- Who authorized the connection?
- What permissions were granted?
- What data can be accessed?
- Is the connection still required?
- Is the provider approved?
- Can access be restricted?
Unnecessary OAuth integrations should be revoked.
17. SSO and MFA
Determine whether the SaaS application supports:
- SSO
- MFA
- Role-based access
- Administrative controls
- User lifecycle integration
Where organizational requirements apply, SSO and MFA should be preferred over unmanaged individual accounts.
18. Security Assessment
Depending on risk, review:
- Security architecture
- Authentication
- Authorization
- Encryption
- Vulnerability management
- Secure development
- Logging
- Monitoring
- Incident response
- Backup
- Business continuity
- Data deletion
- Subprocessors
- Security certifications
- Independent assurance reports
Possible evidence includes:
- SOC 2 report
- ISO/IEC 27001 certificate
- Penetration-test summary
- Security documentation
- Trust-center information
- Data-processing documentation
- Security questionnaire
A security certification should be reviewed for its actual scope, entity, service, and validity rather than treated as automatic proof that every organizational requirement is satisfied.
19. Supplier Due Diligence
Where appropriate, perform supplier due diligence.
Review:
- Provider identity
- Service
- Ownership
- Security
- Privacy
- Data location
- Subprocessors
- Incident notification
- Business continuity
- Availability
- Contract
- Termination
- Data deletion
The depth of due diligence should be proportionate to risk.
20. Contract Review
Determine whether a formal contract exists.
Review:
- Service agreement
- Terms of service
- Security requirements
- Confidentiality
- Data processing
- Incident notification
- Subprocessors
- Data location
- Data deletion
- Availability
- Audit/assurance
- Termination
Free SaaS should not automatically be assumed to have no security implications.
21. DPA Review
Where personal data processing creates a requirement for a Data Processing Agreement or equivalent contractual arrangement, verify:
- Parties
- Processing purpose
- Data categories
- Data-subject categories
- Security measures
- Subprocessors
- International transfers
- Breach notification
- Data-subject rights
- Retention
- Deletion/return
- Audit/assurance
Record the DPA status.
22. AI SaaS Review
AI SaaS requires additional consideration.
Examples:
- Generative AI
- AI writing tools
- AI coding assistants
- AI meeting transcription
- AI customer-support tools
- AI document analysis
- AI security tools
Review:
- What information is submitted?
- Is customer data permitted?
- Is confidential information permitted?
- Is information used for model training?
- Are prompts retained?
- Are outputs retained?
- Are subprocessors involved?
- What administrative controls exist?
- Is enterprise data isolation available?
- Can users disable training/data retention where applicable?
Example:
An employee should not upload confidential customer information into a public AI service merely because the service is freely available.
23. Developer SaaS Review
Developer-related SaaS can create significant security exposure.
Review applications such as:
- Code assistants
- Code analysis tools
- Package repositories
- API testing tools
- CI/CD services
- Error monitoring
- Developer collaboration platforms
- Online IDEs
Determine whether the service can access:
- Source code
- Secrets
- Environment variables
- Production systems
- Build pipelines
- Customer information
24. Browser Extensions
Browser extensions should also be considered where they can access organizational information.
Review:
- Extension name
- Publisher
- Permissions
- Browser access
- Data collection
- Business purpose
- User population
- Security review
- Approval status
An apparently simple browser extension may have extensive access to web pages or corporate applications.
25. SaaS Risk Assessment
Assess risks based on factors such as:
- Information sensitivity
- Customer data
- Personal data
- Access level
- Production access
- Privileged access
- API access
- Supplier criticality
- Business dependency
- Availability requirements
- Data location
- Subprocessors
- Security assurance
- Regulatory requirements
- Exit complexity
Example risk formula:
Information + Access + Dependency + Threat + Vulnerability + Impact → SaaS Risk
26. Suggested SaaS Risk Tiers
Low
Typical characteristics:
- Public/internal information
- No sensitive data
- No production access
- Limited business dependency
- Minimal integration
Medium
Typical characteristics:
- Internal/confidential information
- Multiple users
- Business-process dependency
- Corporate identity integration
- Limited personal data
High
Typical characteristics:
- Customer or personal data
- Source code
- Significant business dependency
- API integrations
- Production-related access
- Important supplier dependency
Critical
Typical characteristics:
- Highly sensitive information
- Privileged production access
- Major customer-facing dependency
- Critical business process
- Significant regulatory or contractual impact
- Difficult replacement or exit
These categories are examples and should be adapted to the organization’s risk methodology.
27. Shadow IT Decision
After assessment, determine the appropriate action.
Possible outcomes:
Approve
The service meets requirements and can be formally adopted.
Approve With Conditions
The service can continue subject to controls.
Example:
Approved only for non-confidential information.
Restrict
Usage is limited to defined users, data, or functionality.
Replace
An approved alternative should be used.
Remove
The service should no longer be used.
Further Assessment
More information is required before a decision can be made.
28. Corrective Actions
Typical actions include:
- Remove unnecessary users
- Enable SSO
- Enable MFA
- Reduce OAuth permissions
- Remove customer data
- Stop uploading confidential information
- Execute DPA
- Complete supplier assessment
- Configure retention
- Restrict integrations
- Move to an enterprise plan
- Replace the SaaS application
- Disable the service
29. SaaS Monitoring
Approved SaaS applications should continue to be monitored according to risk.
Monitor:
- Security incidents
- Provider changes
- New subprocessors
- Data-location changes
- Contract changes
- Security assurance expiry
- Major vulnerabilities
- Access changes
- Increased business dependency
- Service discontinuation
- Material product changes
Shadow IT discovery should also continue because new SaaS applications can appear after the initial review.
30. Review Triggers
Perform an additional review when:
- A new SaaS application is discovered.
- The provider has a security incident.
- The service starts processing sensitive data.
- New integrations are introduced.
- Production access is added.
- A new subprocessor is introduced.
- Data location changes.
- The provider changes its terms materially.
- The business dependency increases.
- Security certification expires.
- The service is discontinued.
- A major organizational change occurs.
31. SaaS Discovery Register
A separate discovery log can help track newly identified services.
| Discovery ID | SaaS | Source | Department | Owner | Date | Shadow IT | Status | Risk | Action |
|---|---|---|---|---|---|---|---|---|---|
| SD-001 | Example AI Tool | SSO | Engineering | CTO | Yes | Under Review | High | Assess | |
| SD-002 | Example File Tool | Finance | Finance | CFO | Yes | Unknown | Medium | Investigate |
This helps demonstrate that the organization actively looks for unmanaged technology.
32. AWS SaaS / Shadow IT Example
Consider a SaaS startup using AWS as its production cloud.
During a quarterly review, the security team discovers that developers have connected an online AI coding assistant to GitHub repositories.
The review identifies:
Application: AI coding assistant
Users: Engineering team
Integration: GitHub OAuth
Information: Source code
Access: Repository access
Business Purpose: Code assistance
Shadow IT: Yes
Risk: High
The organization then investigates:
- What repositories can the tool access?
- Can it access private repositories?
- Can it access secrets?
- Is source code retained?
- Is customer code used for model training?
- What subprocessors are involved?
- Is enterprise data isolation available?
- Does the provider offer appropriate contractual protections?
Possible treatment could include:
- Approve with controls
- Restrict repository access
- Disable the OAuth integration
- Move users to an approved enterprise solution
The decision should be based on the organization’s security and business requirements rather than simply on the fact that the tool was initially unauthorized.
33. Evidence
Evidence supporting SaaS governance may include:
- SaaS register
- SSO application list
- OAuth application report
- CASB discovery report
- DNS/proxy reports
- Corporate-card subscription records
- Procurement records
- Security assessments
- Supplier questionnaires
- SOC 2/ISO certificates
- Contracts
- DPAs
- Data-flow information
- Access reviews
- Risk assessments
- Approval records
- Remediation tickets
- SaaS retirement evidence
34. Internal Audit Checklist
An auditor may verify:
- SaaS applications are identified.
- Shadow IT discovery mechanisms exist.
- SaaS ownership is defined.
- Business purpose is documented.
- Information processed is identified.
- Information classification is considered.
- Customer data is identified.
- Personal data is identified.
- Access and integrations are assessed.
- OAuth permissions are reviewed.
- SSO/MFA requirements are considered.
- Supplier due diligence is performed where appropriate.
- Security assurance is reviewed.
- DPA requirements are considered.
- AI SaaS receives appropriate assessment.
- Risk is assessed.
- Shadow IT findings are tracked.
- Corrective actions are monitored.
- Approved SaaS is periodically reviewed.
- Unapproved services are addressed.
- Retired services are removed.
- Evidence is retained.
35. Common Mistakes
Avoid:
- Maintaining only a list of formally purchased SaaS.
- Assuming employees will report every application.
- Ignoring free SaaS.
- Ignoring AI tools.
- Ignoring browser extensions.
- Ignoring OAuth integrations.
- Reviewing the application but not the data being uploaded.
- Treating a SOC 2 report or ISO certificate as the complete assessment.
- Ignoring developer tools.
- Ignoring personal accounts used for business.
- Allowing employees to connect SaaS directly to production systems.
- Failing to track unapproved applications to closure.
- Blocking every unknown application without understanding its business purpose.
- Failing to update the register when SaaS usage changes.
36. Relationship With Other ISMS Documents
The SaaS / Shadow IT Register connects with:
Cloud Services Register
Tracks formally recognized cloud services.
Supplier Register
Tracks SaaS providers as suppliers.
Supplier Risk Assessment
Assesses supplier-related risk.
Third-Party Due Diligence Checklist
Supports pre-approval assessment.
Cloud Access Review Checklist
Reviews access to cloud environments and services.
Cloud Exit Checklist
Supports secure SaaS termination.
Data Inventory / RoPA
Identifies personal-data processing.
Software Dependency Inventory
Tracks software components rather than business SaaS applications.
ICT Dependency Register
Tracks critical technology dependencies.
Risk Register
Tracks significant risks arising from SaaS usage.
37. ISO/IEC 27001 Connection
SaaS governance can support applicable ISO/IEC 27001:2022 requirements and controls relating to:
- Information classification
- Access control
- Identity management
- Cloud services
- Supplier relationships
- Supplier service monitoring
- Information security in the use of cloud services
- Information deletion
- Data leakage prevention
- Secure authentication
- Logging and monitoring
- Change management
- Incident management
- Privacy and protection of personal information
The exact controls should be determined through the organization’s:
- ISMS scope
- Risk assessment
- Risk treatment process
- Statement of Applicability
- Legal requirements
- Contractual requirements
- Business requirements
The register itself is not a universally mandatory ISO document. It is a practical governance mechanism for maintaining visibility and evidence over SaaS usage.
38. Final SaaS / Shadow IT Audit Trail
A complete governance trail should demonstrate:
SaaS Discovered → Owner Identified → Business Purpose Understood → Information Identified → Classification Determined → Access/Integration Reviewed → Supplier Assessed → Privacy Requirements Reviewed → Risk Assessed → Decision Made → Controls Implemented → Approval → Monitoring → Periodic Review → Exit/Removal Where Required
For shadow IT:
Unknown SaaS → Discovery → Validation → Owner Identified → Data/Access Assessment → Risk Assessment → Approve / Restrict / Replace / Remove → Corrective Action → Verification → Register Updated
39. Final Principle
Shadow IT is fundamentally a visibility problem before it is a technology problem.
An organization cannot effectively protect SaaS usage that it does not know exists.
The objective should therefore be:
Discover the service → understand how it is being used → identify the information and access involved → assess the risk → apply appropriate controls → make a documented decision → continue monitoring.
SaaS Governance = Visibility + Ownership + Data Awareness + Access Control + Risk Assessment + Appropriate Approval + Continuous Monitoring.