Cybersecurity for SaaS: build the guardrails early (so you can move faster)

In this KiwiSaaS workshop on the changing cybersecurity threat, David Clearwater hosted Wendy Bennett from Outfox to break down what’s changing for SaaS providers — and what customers and boards are increasingly asking for. Wendy’s key point was simple: security shouldn’t be a blocker. Done well, it’s “guardrails” that help teams ship faster with fewer costly mistakes.

---

Key themes:

1. The “Willy Wonka” trap: when security is bolted on too late
   Wendy shared an example of a product that looked “magical” from the outside, but had critical security gaps underneath because security hadn’t been planned. Controls were bolted on to meet “tick box requirements” for certification, rather than the real needs of the product. The result: teams had to slow down, with “investor confidence… shot,” and uncertainty about competing effectively.

2. Cybersecurity is a business risk — not just a technical one
   Wendy positioned cyber risk as something that impacts trust, revenue, service delivery, legal obligations, reputation, and even fundraising. Her message to SaaS leaders: treat cybersecurity as part of the overall business risk picture, not a separate “IT issue.”

3. What’s changing: credentials, double extortion, and AI-powered social engineering
   A big theme was how many compromises still happen through stolen credentials and access failures — “attackers aren’t hacking in, they’re knocking at the front door.” Wendy also described ransomware shifting into “double extortion,” where attackers take data before encrypting it. Social engineering has evolved too, including AI voice cloning paired with urgent follow-up emails that push people to pay invoices, click links, or log into fake portals.

4. Modern SaaS creates “ecosystem risk” (APIs, dependencies, suppliers-of-suppliers)
   Wendy highlighted how SaaS is built on layers of APIs, integrations, and libraries — often outside a team’s full visibility. “Every connection becomes a potential entry point,” and supply chain exposure isn’t only about your direct supplier, but also who they rely on. She encouraged SaaS teams to ask better questions early (IP protection, breach expectations, data retention, and ownership).

5. AI is powerful — but speed without review increases risk
   AI is being introduced “at pace,” not only as a feature but across the development lifecycle — generating code, reviewing changes, and analysing data. Wendy’s caution was that teams are starting to trust outputs without fully understanding them, and that AI risk isn’t just technical: it can affect product quality, data security, customer trust, and reputation.

6. Shared responsibility breaks down when roles and assumptions aren’t clear
   Beyond cloud infrastructure, Wendy talked about the shared responsibility model between SaaS providers and customers. Providers may be responsible for infrastructure, applications, and data protection, while customers manage access and configuration — but customers can also have “over-trusting assumptions” about how a product works. Wendy referenced an example where a SaaS product was used in a way it “shouldn’t be used,” leading to legal action.

7. Compliance matters — but don’t use it as a reason to delay security
   Wendy noted that many teams avoid compliance until they’re forced into it to go global (ISO 27001, SOC 2, GDPR, and other requirements). Her advice: be honest in reports, don’t “fudge” requirements, and think early about what’s best for your product. Security doesn’t have to be done all at once — but it does need a plan.

8. What boards and customers want now: clarity on risk, cost, and progress
   Wendy said boards want clarity more than more tooling: “I don’t want any more dashboards. I just want to understand what my risks are.” Customers are also asking more, especially as supply chain clauses and government requirements flow down. Wendy talked through measurable ways to show progress, including MFA coverage, phishing rates, patching timelines, cyber spend, insurance, and mean time to detect/respond.

9. Incident response: preparation beats panic
   A major call to action was having an incident response plan that’s written down, accessible, tested, and clear on roles and responsibilities. Wendy stressed that incident response is more than technical fixes — it includes privacy, suppliers, communications, and decision-making under pressure. “Cyber resilience isn’t built in panic, it’s built in preparation.”

She outlined a simple cycle: prep → identify → contain → eradicate → recover → lessons learned, and cautioned that skipping eradication (or paying ransom because it feels easier) can leave attackers in the system.

---

Key takeaways:

• Build security by design early so you don’t have to slow down later to bolt fixes on.

• Assume attackers will target credentials and access first — tighten privileged access and offboarding.

• Treat integrations and suppliers as part of your attack surface: “ecosystem risk” is real.

• Use AI to speed up delivery, but keep a human review loop for outputs and changes.

• Don’t treat compliance as a future problem — plan for what your product actually needs.

• Put an incident response plan in place, test it, and define roles (including privacy + suppliers).

• Report risk to boards in plain language with a small set of KPIs that show progress.
  

Watch the full discussion for all the insights.

---