Your finance team pays for a tool nobody in IT has heard of. A salesperson connected a note-taking app to the company calendar with two clicks, and it now reads every meeting invite. When someone leaves, you close their email account, but you have no list of the other apps they signed into. You need to know what is in use before you can decide what to allow.
\nShadow SaaS is software-as-a-service used for work without the knowledge or approval of the people responsible for IT and security. It is the cloud form of shadow IT, and it is easy to start: a work email and a card are enough. If SaaS itself is new to you, start with What is SaaS?.
\nThink of the keys to an office. Every time someone has a copy cut for a contractor or a friend, the building gets one more key you do not control. Nobody meant harm. But when you change the staff, the copies still open the door.
\nAn OAuth grant is that copy of the key. OAuth is the standard behind buttons such as “Sign in with Google”: the app asks for access to part of your account, such as calendar or files, and keeps it until someone revokes it. The scope is which doors the key opens. A grant that reads only your name and email is a small key. A grant that reads all mail and files is a master key.
\nNone of these routes requires the IT team. That is why a policy that bans shadow SaaS is not enough on its own.
\nNo single source sees everything. The table compares four discovery methods. It is assembled from the vendor documentation cited in each row and from how each method works.
\n| Method | \nWhat it sees | \nWhat it misses | \n
|---|---|---|
| Expense and card records | \nPaid apps, cost, who bought them | \nFree tools, OAuth grants, apps paid by personal cards | \n
| Identity provider app reports | \nApps connected with the company account and their scopes. Google Workspace lists configured and accessed apps under Security > Access and data control > API controls (Google) | \nApps used with a personal login or a separate password | \n
| Network and endpoint logs | \nTraffic to known cloud apps. Microsoft Defender for Cloud Apps matches logs against a catalog of over 31,000 apps, scored on more than 90 risk factors (Microsoft Learn) | \nApps not in the catalog, which “cannot” be discovered by default, and traffic outside your network unless endpoint agents report it | \n
| Asking teams | \nWhy each tool is used, who owns it | \nAnything people forget or prefer not to mention | \n
Use at least two methods. Expenses catch paid apps; identity reports catch the free ones connected to company accounts. Microsoft’s page adds that discovery data is analyzed and updated four times a day, so network-based discovery is continuous once it is running.
\nDiscovery gives you a list. Control means deciding, per app, whether it stays. Google Workspace gives a clear model. Each app can be set to one of four access levels (Google Workspace admin help, as of October 2026):
\nA separate setting covers apps nobody has configured yet. Its default is “Allow users to access any third-party apps”. The other two options allow only apps that request basic sign-in information, or none at all. If you have never looked at that setting, every app your users approve is allowed today. For the wider admin model of the suite, see Google Workspace as SaaS. For what a Microsoft 365 admin owns, see Microsoft 365 as SaaS.
\nShadow SaaS has a cost line as well as a risk line. Example: a labeled hypothetical. An expense review finds three teams paying separately for the same note-taking tool, 4, 6 and 9 seats, each at $10 per seat per month billed monthly.
\nThe bigger gain is control. On the company plan, the 19 accounts can sit behind single sign-on and close when someone leaves.
\nThe review itself takes time, so size it before you start. In a company of 120 employees, suppose each person has approved 3 OAuth apps on average.
\nTwelve hours is under two working days for one person, not a project. Sorting by scope first, mail and files before profile-only grants, puts the risky ones at the top.
\nFor the security controls a vendor should prove before an app is approved, see ISO/IEC 27017 explained.
\nShadow SaaS is work software used without IT’s knowledge, and it arrives through card purchases, free sign-ups, OAuth grants and add-ons inside approved tools. Find it by combining expense records with your identity provider’s app report; in the example, consolidating 19 scattered seats saves 20% and reviewing 360 grants takes about 12 hours. Decide per app, block risky scopes first, give each approved app an owner and repeat the review every quarter.
\n", "image": "https://saascron.com/media/shadow-saas/16x9.jpg", "date_published": "2026-10-22T12:00:00-04:00", "date_modified": "2026-10-22T12:00:00-04:00", "authors": [ { "name": "Ricardo Machado", "url": "https://saascron.com/author/ricardo-machado/" } ], "tags": [ "Security & Compliance", "Shadow IT", "SaaS security", "Oauth", "IT governance" ], "language": "en-US" }, { "id": "https://saascron.com/sspm/", "url": "https://saascron.com/sspm/", "title": "SaaS security posture management (SSPM): what it is and how it works", "summary": "What SSPM checks inside apps such as Microsoft 365 and Google Workspace, how it differs from CASB and CSPM, a free CISA baseline tool and a rollout checklist.", "content_html": "Your company runs Microsoft 365, Google Workspace, a CRM and a dozen other SaaS apps, and each one has security settings that nobody has reviewed since the day it was set up. You want to know whether a tool can check them for you, and what it would find. SaaS security posture management (SSPM) is the category of tools that connects to your SaaS apps through their admin interfaces, reads their settings and compares them with a security baseline. It then lists the risky settings and how to fix them.
\nThe vendor runs and secures the application. The settings, users and data in your tenant stay with you. Microsoft’s shared responsibility matrix marks customer data, “configurations and settings” and “identities and users” as the customer’s job in SaaS, and SSPM tools check that part. For the basics, see What is SaaS?. For that split in one product, see Microsoft 365 as SaaS.
\nThink of a fire inspector in an office building with many tenants. The landlord maintains the walls, lifts and wiring. Each tenant decides who gets a key, which doors stay propped open and which contractors get a pass. The inspector walks through each office, compares those choices with the fire code and leaves a list of what to fix.
\nAn SSPM tool is that inspector for your SaaS tenants. It reads settings through each app’s interfaces, such as:
\nMicrosoft describes SSPM in Defender for Cloud Apps as “surfacing misconfigurations and recommending specific actions” for each connected app. Its recommendations follow standards such as those of the Center for Internet Security (CIS) and the app provider’s own best practices (Microsoft Learn). Its SSPM page shows recommendations for a connected Salesforce app, and lists two prerequisites: a Defender for Cloud Apps license and an app connector for each app.
\nThe same documentation adds OAuth apps to its attack-path views, because a connected app with broad permissions is a route into your data. Independent SSPM vendors sell the same category. AppOmni, for example, describes itself in the FAQ on its homepage as an SSPM platform.
\nThree acronyms sound alike and answer different questions. The table puts them side by side, with examples from Microsoft’s documentation, which covers all three in its products.
\n| Tool | \nWhat it looks at | \nMain question | \nExample from Microsoft’s documentation | \n
|---|---|---|---|
| CASB (cloud access security broker) | \nWhich cloud apps people use, and what they do with data in them | \nWhich apps are in use, and is data leaving safely? | \nShadow IT discovery; discovered apps rated on “more than 90 risk indicators” | \n
| SSPM | \nSettings inside the SaaS apps you have approved | \nAre the approved apps configured safely? | \nSecurity recommendations for connected apps, such as Salesforce | \n
| CSPM (cloud security posture management) | \nYour own resources in infrastructure and platform clouds | \nAre your servers, storage and databases configured safely? | \nDefender for Cloud assessing Azure, AWS and Google Cloud resources | \n
A CSPM tool reads virtual machines, storage buckets and databases. It does not read the sharing settings of your Microsoft 365 tenant or your CRM. If you run both your own cloud infrastructure and many SaaS apps, the two tools cover different ground.
\nYou do not need to buy a tool to see what a baseline looks like. The US Cybersecurity and Infrastructure Security Agency (CISA) set up its Secure Cloud Business Applications (SCuBA) project in 2022. It publishes secure configuration baselines for Microsoft 365 and Google Workspace, and two free assessment tools introduced in 2023:
\nRunning one of these once shows you the kind of findings an SSPM tool produces. What a paid tool adds is more apps, continuous checks and a place to track fixes.
\nExample (hypothetical): a company with 400 employees connected to Microsoft 365. Assume each employee has granted an average of 3 third-party apps access to their account, and that the grants point to 150 distinct apps.
\nThe numbers are assumptions; replace them with your own. The point is the ratio: sorting by risk turns a 25-hour review into a 5-hour first pass.
\nFor how certification fits next to configuration checks, see ISO/IEC 27017 explained. For the Google side, see Google Workspace as SaaS.
\nSSPM tools connect to your SaaS apps, read their security settings and connected OAuth apps, and compare them with a baseline such as CIS or CISA SCuBA. They cover the part the vendor leaves to you, which CASB tools (app usage) and CSPM tools (your own cloud infrastructure) do not. Start with the apps that hold your most sensitive data, sort findings by risk, and re-check on a schedule, because settings drift after the first scan.
\n", "image": "https://saascron.com/media/sspm/16x9.jpg", "date_published": "2026-10-19T12:00:00-04:00", "date_modified": "2026-10-19T12:00:00-04:00", "authors": [ { "name": "Ricardo Machado", "url": "https://saascron.com/author/ricardo-machado/" } ], "tags": [ "Security & Compliance", "SaaS security", "SSPM", "Misconfiguration", "Oauth" ], "language": "en-US" }, { "id": "https://saascron.com/iso-27017-explained/", "url": "https://saascron.com/iso-27017-explained/", "title": "ISO/IEC 27017 explained: cloud security controls for SaaS providers and buyers", "summary": "What ISO/IEC 27017 adds to ISO 27001, the seven cloud-only controls, how certification works and how to read a vendor's certificate before you sign.", "content_html": "A prospect’s security questionnaire asks whether your SaaS product is “ISO 27017 certified”. Or a vendor you are about to sign lists the standard on its trust page. Either way, you are not sure what it proves. ISO/IEC 27017 is a set of cloud-specific security controls that a provider adds on top of an ISO/IEC 27001 certification. Its main job is to spell out which security tasks belong to the provider and which belong to you.
\nThat split matters to two readers: the SaaS vendor that wants to pass enterprise security reviews, and the buyer who has to decide what a certificate actually covers. If the basic idea of SaaS and “who manages what” is new to you, start with What is SaaS? and come back.
\nThink of an office building that has passed its general safety inspection. Now the owner turns it into shared space for many tenants. The inspector adds a second list: who maintains the shared corridors, who holds the master keys, and what happens to a tenant’s furniture when the lease ends.
\nThe general inspection is ISO/IEC 27001. It certifies an information security management system (ISMS): the policies, risk assessments and controls a company runs to protect information. ISO/IEC 27002 is the catalog of controls that an ISMS draws from. ISO/IEC 27017 is the extra list for shared cloud services. It adds cloud guidance to existing controls and introduces controls that only make sense in the cloud.
\nTwo consequences follow. First, nobody is certified to ISO/IEC 27017 alone. Microsoft, for example, says its cloud services “are audited once a year for the ISO/IEC 27017:2015 code of practice as part of the certification process for ISO/IEC 27001:2013” (Microsoft Learn). Second, the standard is written for both sides. It gives controls to cloud service providers and to cloud service customers, so it also tells you, the buyer, what to expect and what to do yourself.
\nMost certificates you will see in late 2026 still cite ISO/IEC 27017:2015. That edition, according to Microsoft’s summary, gives cloud guidance on 37 controls of ISO/IEC 27002:2013 and adds seven new controls.
\nA second edition, ISO/IEC 27017:2026, was published on July 27, 2026 (IEC Webstore). It is 39 pages long and provides “additional guidance for relevant controls specified in ISO/IEC 27002:2022” plus “additional controls with guidance that specifically relate to cloud services.” It applies to every cloud deployment model, private cloud included.
\nFor you, the practical point is the year printed on the certificate. AWS describes its own certificate against the 2015 edition (AWS), and so does Microsoft. A 2015 certificate is not wrong in October 2026. It does mean the vendor still has to move to the new edition at a future audit, and you can ask when.
\nThe table below turns Microsoft’s list of the seven new 2015 controls into the question each one lets you ask a vendor. The “who acts” column is the reading most audits apply; your contract decides the details.
\n| Control area | \nWhat it covers | \nWho acts | \nAsk the vendor | \n
|---|---|---|---|
| Shared roles | \nWhich security tasks belong to the provider and which to the customer | \nBoth | \n“Where is your shared responsibility document?” | \n
| Asset removal | \nReturn and deletion of your data when the contract ends | \nProvider | \n“How soon after termination is customer data deleted, and can it be exported first?” | \n
| Tenant separation | \nKeeping one customer’s virtual environment apart from another’s | \nProvider | \n“How do you isolate tenants, and is it tested?” | \n
| Machine hardening | \nSecuring the virtual machines that run the service | \nProvider | \n“Which hardening baseline do you follow?” | \n
| Admin procedures | \nDocumented procedures for administrative operations | \nProvider | \n“Can staff reach customer data, and is that logged?” | \n
| Customer monitoring | \nLetting you monitor relevant activity in your account | \nBoth | \n“Which logs can customers export, and for how long?” | \n
| Network alignment | \nMatching security of virtual and physical networks | \nProvider | \nUsually covered by the audit; ask only if you run regulated workloads | \n
Notice that two of the seven controls need action from you. A provider can give you logs and a responsibility matrix, but reading the logs and doing your half is your job.
\nAn accredited certification body audits the ISMS against ISO/IEC 27001 and, when the company asks for it, against ISO/IEC 27017 as well. The rules that certification bodies follow, in ISO/IEC 17021-1, set a three-year cycle: an initial certification audit, surveillance audits in the following years, and a recertification audit before the certificate expires. AWS, for instance, names its auditor as EY CertifyPoint, accredited by the Dutch Accreditation Council.
\nThree parts of the certificate matter more than the logo. The scope names the services, sites or regions covered. The dates tell you whether the evidence is current. The Statement of Applicability, which ISO/IEC 27001 requires every certified company to keep, lists which controls the company applies and which it excludes, with a reason for each.
\nExample: a vendor’s certificate was issued on June 15, 2025, with a three-year validity. It expires on June 14, 2028. You sign a 36-month contract on November 1, 2026, so the contract runs to October 31, 2029.
\nThat is normal. It is also why the contract should require the vendor to share its renewed certificate, not just the one on the trust page today.
\nUse this list when a vendor sends an ISO/IEC 27001 certificate that mentions ISO/IEC 27017.
\nISO/IEC 27017 adds cloud-specific security controls to an ISO/IEC 27001 certification and is never certified on its own. Its most useful control for you is the shared responsibility split, because two of the seven 2015 controls need action from the customer, not the provider. Before you sign, check the edition, the scope and the expiry date on the certificate, and write renewal evidence into the contract.
\n", "image": "https://saascron.com/media/iso-27017-explained/16x9.jpg", "date_published": "2026-10-17T07:00:00-04:00", "date_modified": "2026-10-17T07:00:00-04:00", "authors": [ { "name": "Ricardo Machado", "url": "https://saascron.com/author/ricardo-machado/" } ], "tags": [ "Security & Compliance", "SaaS security", "Compliance", "ISO 27001", "Cloud computing" ], "language": "en-US" } ] }