Assessing SaaS Risk Proportionately
Reviewing every application to the same depth guarantees that nothing gets reviewed. Tiering by data and access makes the process fast enough to actually run.
Procedure · 714 words
A security review process that takes six weeks for a note-taking tool will be bypassed, and the bypassing is rational. Proportionality is what makes the process survive.
The two questions that determine the tier
What data goes in? Public, internal, confidential, regulated, or personal data at scale.
What access does it get? None beyond its own data, read access to a platform, write access, or administrative access to something else.
Everything else is secondary. Vendor size, price, popularity and who is asking matter far less than these two.
The tiers
Low. Public or internal data, no integration. A formatting tool, a diagramming tool with no company data.
Review: register it, name an owner, confirm the data classification. Days, not weeks.
Medium. Confidential business data, or read access to a platform.
Review: vendor security documentation, data location, breach history, contract terms, SSO support. A week.
High. Regulated data, personal data at scale, or write and administrative access to core platforms.
Review: full assessment, security questionnaire, data protection impact assessment where required, contract negotiation, penetration test evidence, sub-processor list. Weeks, appropriately.
Publish the tiering criteria so requesters can predict which they are in.
What to ask at each tier
Low: what data, who owns it, does it support SSO.
Medium, add: where is data hosted, is it encrypted, what certifications, what is the breach notification commitment, what happens to our data on termination, who are the sub-processors.
High, add: penetration test summary, incident history, data protection terms, deletion verification, audit rights, and evidence rather than assertions.
Ask for evidence at the top tier. A certification logo is not a report and vendors at this level can produce the report under an agreement.
Where reviews go wrong
Same depth for everything, which means nothing gets reviewed properly and everything takes too long.
A questionnaire with two hundred questions sent to a four-person vendor who cannot answer it, producing either a refusal or fiction.
Reviewing at purchase and never again. Vendors change, get acquired and have incidents.
No route to say no, so every review concludes with acceptance and conditions nobody tracks.
No record of the decision, so the same application is reviewed again next year from scratch.
Re-review triggers
Annually for high tier, on the register's schedule.
On acquisition of the vendor, which changes the data position and sometimes the jurisdiction.
On a breach, theirs.
On a change in what data goes in, which is why the classification field needs maintaining.
On a change in integration scope, particularly new OAuth grants.
Recording the outcome
Tier, date, reviewer, decision, conditions, next review date.
Conditions tracked to completion, or they are aspirations.
Attached to the register entry, not in a separate system, so that the person answering a question about the application finds it.
The fast path is the control
Counter-intuitively, the way to get more applications reviewed is to make most reviews trivial.
A low-tier decision in two days means people use the process.
A process that takes six weeks for everything means people use a card, and you review nothing because you know about nothing.
The reassessment trigger list
A one-time assessment expires quietly. These six events should reopen it.
Vendor acquisition, which changes ownership, jurisdiction and frequently the security programme.
A publicly reported breach at the vendor.
A change in what data goes in, which is why the classification needs annual confirmation.
A new integration, particularly one connecting the application to a higher-classified system.
A material change in user count, which changes the exposure.
A change in where it is hosted or processed.
Subscribe to vendor notifications where offered and route them somewhere they will be read, since several of these arrive as an email nobody owns.
Recording a decision to accept
Not every finding gets fixed, and an accepted risk that is not recorded becomes an unmanaged one.
What the finding is, specifically.
Why it is being accepted: cost, no alternative, low exposure, mitigating controls elsewhere.
Who accepted it, by name and at what level of seniority.
What compensating controls apply.
When it will be revisited, with a date.
Attach it to the register entry rather than filing it separately.
Review accepted risks annually. Circumstances change, alternatives appear, and an acceptance from three years ago is frequently no longer the decision anyone would make today.