Part one made the case that a SaaS data theft is not one lucky break. It is a chain of five gates, and the attacker has to clear every one of them: talk a help desk into a reset, land on a machine nobody vetted, reach the platform from a network nobody restricted, find an account already holding rights to everything, and move an enormous volume of data without tripping anything.
Part one covered the gates that decide whether somebody gets a working session. Part two covered the gate that decides how much that session is worth. This one covers the two at either end of the middle: where the session is allowed to come from, and what you can prove about it afterward.
Gate 3 asks whether the session is coming from somewhere you trust. Gate 5 asks whether you would be able to tell, afterward, what it took. As with standing access in part two, the control exists and the vendor documents it well, and whether you actually have it depends on a line item somebody negotiated before you got there.
Gate 3. Network restrictions: shrink the map
This is the gate people skip because it feels dated. It is not.
If your Salesforce org contains PHI, there is no business reason for it to be reachable from arbitrary residential broadband, a VPS in another country, or a commercial proxy pool. Restrict critical SaaS to your known office egress addresses and your validated zero trust or SASE egress ranges. If you run something like Cloudflare Access, Zscaler, or Netskope, you already have a small, stable, attestable set of source addresses. Use them.
Every platform of consequence can do this. Each one calls it something different and gates it differently.
| Platform | What it is called | Worth knowing |
|---|---|---|
| Salesforce | Login IP Ranges, set per profile | Trusted IP Ranges is a different, much weaker setting |
| Snowflake | Network policies | Included in every edition |
| Okta | Network Zones, used as policy conditions | Blocking anonymizer zones is a sane default |
| Microsoft 365 | Conditional Access named locations | Needs Entra ID P1 or higher |
| Google Workspace | Context-Aware Access | Higher editions only |
| Databricks | IP access lists, plus front-end Private Link | Enterprise tier on AWS |
Two of those deserve more than a table row.
Salesforce, because the names are a trap. Login IP Ranges, set per profile, are a hard restriction: outside the range, the login is refused. Trusted IP Ranges, under Setup → Security → Network Access, are org-wide and only let users skip identity verification. They block nothing. Set Login IP Ranges on the profiles that touch sensitive data, then turn on Enforce login IP ranges on every request, which is off by default and without which the range is checked at login and never re-evaluated, so a session that moves elsewhere keeps working. Then audit your connected apps for relaxed IP restrictions, an OAuth policy that lets an app bypass the org’s enforcement entirely. Given that the long-running ShinyHunters Salesforce campaign works by tricking employees into authorizing an attacker-controlled connected app impersonating Data Loader, an unreviewed connected app inventory is not a paperwork problem.
Private connectivity, because allowlisting has a ceiling. An IP allowlist still leaves the service reachable over the public internet. You are filtering who may knock at a door that stays open to everyone. Snowflake and Databricks both sell private connectivity that puts a private endpoint inside your own network instead, and if either holds your regulated data it is worth pricing. Snowflake’s sits on Business Critical Edition, a tier above the Enterprise Edition that ACCESS_HISTORY needs, which is the recurring lesson of this series: map every tier-gated control against a single edition before you negotiate, or you will buy the same platform twice. Then know the trap. IP access lists only filter traffic arriving over the public internet, so private connectivity does not extend your allowlist across the private path, and unless you also disable public network access the public endpoint stays a perfectly good route for anyone holding a valid session. Private connectivity is only a control once the public door is shut. Databricks can go further still, splitting workspaces so that sensitive catalogs are reachable only over the private path, but that is an architecture conversation rather than a setting.
The honest caveat: IP restriction is not a perfect control. A residential proxy in the right metro area defeats a coarse geo rule, and remote-heavy organizations have a real exceptions problem. But narrow allowlists tied to zero trust egress are a very different proposition than “block Russia,” and they turn “log in from anywhere with the password” into “log in from anywhere with the password and a foothold on our network path.”
Gate 5. Logging: the part you have to buy
Now the uncomfortable one. In most SaaS platforms, the logging you need to investigate a breach is not what you get by default, and in several cases it is a line item you have to purchase.
Salesforce. Standard Setup Audit Trail tells you about configuration changes. It does not tell you that a user ran a report and exported 40,000 rows. The detailed forensic layer, covering logins, API calls, report exports, URI hits, and Apex execution, is Event Monitoring, sold as part of Salesforce Shield. Pricing is typically quoted as a percentage of your Salesforce spend, commonly around 10%, which on a large org is not a rounding error. Base Event Log Files also expire quickly, so extended retention is a further add-on.
This matters specifically for HIPAA. The Security Rule’s audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems containing ePHI, and the information system activity review requirement at 164.308(a)(1)(ii)(D) requires you to actually look at them. If your CRM holds PHI and your only record of data access is the standard audit trail, you cannot answer the question every breach investigation opens with: what did they actually read? Shield is the product that answers it, and you have to buy it before the incident, not during. Note also that Salesforce’s native retention windows fall well short of HIPAA’s six-year documentation retention, so plan to stream logs into a SIEM or a log lake you control.
Snowflake. LOGIN_HISTORY is available everywhere. ACCESS_HISTORY, the view that tells you which tables and columns a query actually touched, requires Enterprise Edition or higher. That is exactly the view you need after a mass exfiltration, and it is exactly the view a Standard Edition customer does not have.
Okta. The System Log is included, but retention is 90 days. Breaches are routinely discovered later than that. Configure Log Streaming to your SIEM or S3 now so the evidence still exists when you need it.
The pattern across all three: the vendor sells you authentication in the base tier and sells you accountability separately. Budget accordingly, and treat “does this tier produce the logs my regulator expects?” as a procurement question rather than an engineering one.
Alerts do not come in the box
Buying the logging is necessary and not sufficient. Turning on Shield gives you event log files. It does not give you a phone call at 2am. Nobody ships useful detections for your business by default, because what counts as abnormal depends on what your business does.
You have to build them. The detections worth writing first are unglamorous and mostly volumetric:
- Bulk export. A report or query returning row counts far outside that user’s baseline. Salesforce Shield’s Transaction Security Policies can block or alert on this in real time. In Snowflake, alert on query result row counts and large unloads to external stages.
- New or unusual OAuth grant. A connected app authorized for the first time, especially by a non-admin, and most especially one asking for broad API scopes.
- Access from a new ASN, country, or hosting provider, and impossible travel between sessions.
- Sustained access outside working hours, particularly a session that runs for days. Reported exfiltration in this campaign is measured in days of steady pull rather than a single smash and grab, which means it is a window a volumetric alert has time to close.
- Help desk and identity events: MFA factor reset, factor enrollment from a new device, password reset followed quickly by a large data pull. This is the signature of the social engineering playbook, and it is detectable in the Okta System Log.
- Privilege and permission set changes on profiles with access to sensitive objects.
Then, and this is the step people skip, decide who responds and what they do. An alert firing into a channel nobody owns is worse than no alert, because it creates a record showing you saw it.
The procurement checklist
Both of these gates are bought before they are configured, which makes them a different kind of work than hardening a help desk. The short list:
- Inventory which SaaS platforms hold your regulated data, then map every tier-gated control you want against a single edition per platform. Do this once, in a spreadsheet. It is the only way to avoid discovering that private connectivity and query-level audit history sit on different tiers of the same product.
- Apply network restrictions to that list, using zero trust egress ranges where you have them. In Salesforce, verify Login IP Ranges are set per profile, confirm enforcement on every request, and audit connected apps for relaxed IP restrictions.
- Price private connectivity for Snowflake and Databricks if they hold regulated data, and confirm public network access is actually disabled once it is in place. Private Link with the public endpoint still open is not a control.
- Confirm what your current license tier logs, and whether that satisfies your regulatory obligations. Ask the question before renewal, not during an incident.
- Stream the logs somewhere you control, with retention matching your obligations rather than the vendor’s default. Okta’s 90 days and Salesforce’s native windows both fall short of HIPAA’s six years.
- Write five detections and test them. Start with bulk export and new OAuth grants, and decide who responds before you turn them on.
The pattern worth naming: the vendor sells you authentication in the base tier and sells you accountability separately. That is a procurement question wearing an engineering costume, and it is answered most cheaply at renewal.
If you want help working out which tier you are actually on and what it does not cover, our SaaS Security & Access Assessment covers network restrictions, device trust, conditional access, and the license-tier question across Microsoft 365, Google Workspace, Salesforce, and the rest of your stack. If your exposure runs through the vendors you depend on rather than your own tenant, pair it with a vendor risk assessment.
And if you think something is happening right now, call (608) 448-6075 or email with INCIDENT in the subject line.