What to take away
ISO 27001 does not ask you to have zero risky apps. It asks you to know what you rely on, decide about it, and prove those decisions are reviewed. For SaaS and OAuth apps, that means four artifacts: a dated inventory, a named owner per app, a recorded decision (approved, not approved, needs review), and a trail showing what happened to the apps you did not approve. If you already audit OAuth grants, most of the work is done. What is usually missing is the packaging.
1. Know which controls your auditor will look at
Your auditor will ask which cloud services and third-party apps touch company data, who approved them, and how you know that is still true. For most SMBs, the answer lives in a spreadsheet from last year’s audit and in the admin consoles of Google Workspace or Microsoft 365. This guide shows how to turn that scattered work into evidence that holds up: dated, owned, and mapped to the right ISO 27001:2022 controls.
ISO/IEC 27001:2022 regrouped supplier and cloud topics in Annex A. The following controls apply most directly to third-party SaaS and OAuth apps. Your Statement of Applicability decides which are in scope. One clean mapping beats five loose ones.
| Annex A control (2022) | What it means for SaaS / OAuth apps | Evidence that usually works |
|---|---|---|
| 5.9 — Inventory of information and other associated assets | Cloud apps that hold or process your data are assets to inventory. | Dated app inventory with an owner per app. |
| 5.15 — Access control | Rules for who and what can access company data, apps included. | Written policy on app approval and OAuth consent. |
| 5.18 — Access rights | Access is granted, reviewed and removed in line with the policy. | Access review records across your SaaS apps; revocation trail for app grants. |
| 5.19 — Information security in supplier relationships | You manage risks from suppliers, SaaS vendors included. | Supplier list with criticality and risk notes. |
| 5.20 — Addressing information security within supplier agreements | Security requirements are part of the contract. | DPA / security terms for critical vendors. |
| 5.21 — Managing information security in the ICT supply chain | Risks from the vendor’s own dependencies. | Notes on subprocessors for critical apps. |
| 5.22 — Monitoring, review and change management of supplier services | You keep watching suppliers after onboarding. | Periodic review log; breach and CVE follow-up. |
| 5.23 — Information security for use of cloud services | Processes to acquire, use, manage and exit cloud services. | Cloud service policy plus approval and exit records. |
| 8.8 — Management of technical vulnerabilities | Known vulnerabilities in what you use are assessed. | Log of CVEs reviewed for critical apps. |
References: ISO — ISO/IEC 27001:2022
2. Build an inventory that includes what nobody approved
Admin-installed apps are the easy part. The ones that matter are the apps employees connected themselves, like an AI note-taker with calendar access or a PDF tool with Drive scopes. Those show up as OAuth grants in your identity provider, not in your procurement records.
Keep the source of each signal. “We saw it in browser traffic” and “Google reports an OAuth grant with Drive read access” are different levels of proof, and your auditor may ask which one you have.
For each app, record at minimum:
- App name and vendor.
- How you know it is used: OAuth grant, SSO assignment, invoice or email signup.
- Scopes or permissions granted, and to how many users.
- Business owner: a person, not “IT”.
- Data it touches and a criticality level.
- Decision and date of decision.
3. Assign an owner and record a decision
An inventory without decisions is just a list. For every app, the owner picks one of three states: approved, not approved, or needs review. Write down why in one line, and put a date on it.
This is where lean teams usually stall: IT does not know whether the marketing team needs that tool, and marketing does not know the tool can read every file in the shared drive. Put the question to the person who uses the app. They know the business need; you set the rule.
4. Close the loop on unapproved apps
For apps marked not approved, the auditor wants to see what happened next.
“We told people in Slack” is not evidence of revocation. A grant that disappeared from the source system, with a date, is. Check in the source, Google Workspace or Microsoft 365, not just in the ticket.
Record who acted and when for each outcome:
- The user removed the grant: date and actor.
- An admin revoked it centrally: date and actor.
- An exception was granted: end date and compensating measure.
5. Keep it continuous, not annual
A once-a-year export proves your posture on the day you ran it. Control 5.22 is about monitoring over time, and new OAuth grants appear weekly.
Drata’s October 2026 survey of 309 IT and security leaders and practitioners in the US, UK and Canada found that 85% reported at least one third-party-related security incident in the past 12 months. Respondents with the most incidents were also the most likely to report insufficient assessment capacity. This survey is not SMB-specific or an elba customer metric; it supports reviewing suppliers between annual audits.
A realistic SMB cadence:
- Weekly or continuous: flag new apps and new high-risk scopes and route them to an owner.
- Quarterly: owners reconfirm critical apps; stale “needs review” items get a decision.
- On vendor news: a disclosed breach or critical CVE in an app you use triggers a review entry.
- Before the audit: export the inventory, decisions and revocation trail with dates.
References: Drata — Third-party incidents survey, 6 October 2026
6. Package the evidence pack
Put the following artifacts in one folder the auditor can walk through. State residual risk honestly: “Browser extensions are inventoried but not centrally blocked” is a better answer than a claim you cannot back up.
- Policy: approved-app and OAuth consent rules (5.15, 5.23).
- Dated inventory export with owners and criticality (5.9, 5.19).
- Decision log: approved, not approved or needs review, with dates (5.19, 5.23).
- Revocation and exception trail (5.18).
- Review log: quarterly reconfirmations, vendor breach and CVE follow-ups (5.22, 8.8).
- Contracts and DPAs for critical vendors (5.20, 5.21).
References: ISO — ISO/IEC 27001:2022
How Elba supports this work
Elba does not certify you for ISO 27001 or make you compliant. Certification and conformity depend on your ISMS and its assessment. Elba reduces the manual work behind the evidence. This guide describes an evidence workflow, not legal advice.
- One inventory with its sources. Third-Party Apps combines OAuth grants and accounts from connected sources such as Google Workspace, Microsoft 365 and Okta, email activity, Browser Security observations and installed browser extensions into one application inventory. Each signal keeps how it was established: confirmed by a connected source, supported by email activity, or observed in the browser, with first- and last-seen dates.
- Access reviews across supported connected applications. Access-rights evidence for control 5.18 comes from the supported connected apps themselves rather than from a spreadsheet. A catalogue entry alone does not establish connected access-review coverage.
- Browser-side coverage on four browsers. Browser Security runs on Chrome, Edge, Firefox and Safari to show which apps are used in the browser. Installed-extension inventory is available on Chrome, Edge and Firefox; Safari does not expose that list.
- Owners and decisions. You can assign an owner, set business criticality, and set an app’s usage policy: Not reviewed, Needs review, Approved or Not approved.
- Vendor signals. The Radar flags risky permissions, high and critical CVEs, vendor data breaches and unapproved AI apps, and can be exported for offline review.
- Employee decisions and remediation. Playbooks or an admin can send a permission issue to the employee who granted it. In their checklist, the employee can keep the app or revoke permissions where the source supports direct revocation. Configured Playbooks can distribute issues or run source-supported remediation. Available actions depend on the source and configuration. Employee decisions and verified remediation outcomes remain distinct; access-review decisions do not prove verified revocation. The issue history records what happened.
- Browser extensions appear in the inventory with their installations, but are not remediated or blocked automatically.
References: Elba — Third-party apps · Elba — Playbooks
Checklist: third-party SaaS and OAuth evidence
Your checks stay on this page and reset when you reload it.
Common questions
Does ISO 27001 require a specific SaaS management tool?
No. The standard asks for controls and evidence, not a particular tool. A well-maintained spreadsheet can support an audit. Tooling mainly helps keep the inventory current and the decisions traceable.
Are OAuth apps suppliers under ISO 27001?
Usually yes, if they process or access company information. Controls 5.19 and 5.23 cover supplier relationships and cloud services. A free app connected by one employee still belongs in the review when it can read company data. Your Statement of Applicability determines the controls in scope.
How far back does evidence need to go?
That depends on your audit cycle and your auditor. A surveillance audit generally examines whether controls operated over the period since the last audit, so dated records across that period carry more weight than a single recent export.
Does this help with SOC 2 or cyber insurance too?
Often, yes. The same artifacts, inventory, owners, decisions and revocation trail, can answer vendor-management questions in SOC 2 and insurance questionnaires. Check each framework’s exact wording.
Sources & further reading
Primary documentation used to review this guide. Product settings and edition requirements can change; check the linked documentation before making changes.