There is a comforting story business owners like to tell themselves.
If you build custom software, security is your responsibility. If you buy an established platform, security becomes somebody else’s problem.
Pay the subscription. Receive the compliance badge. Sleep peacefully.
The original comment that inspired this series put it like this:
“You want it to be secure and be able to pass off security liability? You use another platform.”
That sounds reassuring until you think about it for ten seconds.
Using established software can absolutely be the right decision. A large, well-run SaaS company can afford dedicated security teams, monitoring, infrastructure, audits, backups and people who understand phrases like “credential stuffing” without needing to discreetly ask ChatGPT what they mean.
But “the platform has security” and “your business is secure” are not the same sentence.
You can rent an office in a building with cameras, guards and reinforced doors. If you give a keycard to every freelancer you have hired since 2019, the building is not really the problem.
The platform secures the platform
The company providing your software is responsible for protecting its infrastructure, maintaining the application, fixing vulnerabilities and securing the parts of the system it controls.
You are still responsible for what happens inside your account.
That includes:
- who has access
- which permissions they have
- whether multi-factor authentication is enabled
- which integrations can read or change your data
- where exported data ends up
- whether former employees and freelancers still have accounts
- what happens when somebody’s login details are compromised
- whether anyone is looking at the security logs
- whether you have a plan if the service becomes unavailable
This is not an obscure opinion held by custom developers trying to frighten people away from SaaS.
The UK National Cyber Security Centre describes SaaS security as a shared responsibility. Its guidance covers user access, onboarding and offboarding, authentication, permissions, integrations, backups, monitoring and incident response.
In other words, quite a lot remains your problem.
Your SaaS account can still be a circus
The software itself can be secure while your particular account is an administrative crime scene.
And that assumes the software itself is secure.
SaaS is a delivery and billing model. It is not a security certification.
The fact that software has a login page, several pricing tiers and a button inviting you to book a demo does not mean there is an enterprise security team behind it.
Some SaaS products are operated by large companies with dedicated security engineers and mature processes.
Some are built by excellent small teams that take security seriously.
Others are held together by one founder, three contractors, seventeen integrations and a landing page that uses the word “enterprise” with considerable confidence.
Paying monthly does not automatically make software safer than something built specifically for your business. It just means the software sends you an invoice every month.
Even when the platform is properly secured, your account can still have problems.
Maybe everyone is an administrator because working out the permissions looked annoying.
Maybe the freelancer who built a funnel six months ago can still access every client account.
Maybe three people share one login because buying another seat would cost money.
Maybe multi-factor authentication is technically available, but nobody enabled it.
Maybe the password is the same one somebody uses for Canva, Netflix and a gym membership they cancelled in 2018.
Maybe an automation tool has permission to read every customer record because somebody clicked Allow without checking what it was asking for.
Maybe customer exports are sitting in the Downloads folder of four different laptops.
None of those problems disappear because the platform’s website is covered in impressive security badges.
HighLevel is especially fond of telling you how secure HighLevel is
HighLevel is a useful example because many people in my audience know it well, and because it is marketed with a level of religious devotion I personally find difficult to participate in.
Its privacy and security page advertises enterprise-grade security, annual SOC 2 Type II assessments, encryption, compliance programmes and various internal security controls.
Its documentation also explains that customers can manage users, roles and permissions.
Those are claims and features worth examining.
They are not a reason to turn off your brain.
HighLevel’s own user-access documentation tells customers to follow the principle of least privilege, avoid unnecessary agency-wide access and review user access periodically.
Why?
Because HighLevel has no idea whether the person you added to your agency account last year still works with you.
It does not know that the virtual assistant who only needed to update one calendar can now see unrelated client information.
It cannot tell whether you gave someone administrative access because they genuinely needed it or because selecting every permission was quicker.
HighLevel can provide the controls. Somebody in your business still has to use them properly.
More importantly, its own security documentation says this:
Using HighLevel does not, by itself, make you GDPR compliant.
That is not my interpretation. That comes from HighLevel’s own security and compliance overview.
Even HighLevel is not claiming that buying HighLevel magically completes compliance for you.
That particular fantasy usually comes from the people selling it, especially when an affiliate commission is involved.
Funny how “shared responsibility” becomes much less prominent when somebody wants you to click their link.
WordPress does not update the plugins you abandoned three years ago
WordPress is not SaaS in exactly the same way as HighLevel, ClickFunnels or Systeme.io, but the same faulty reasoning appears constantly.
People choose a familiar platform and decide the familiar platform must therefore be safe.
A WordPress website is rarely just WordPress. It is WordPress core, hosting, a theme, a collection of plugins, user accounts, passwords, file permissions, backups and whatever unusual decisions were made by the last four people who worked on it.
The official WordPress security guidance says the most important thing site owners can do is keep WordPress, themes and plugins updated. It also recommends choosing actively maintained plugins and deleting plugins that are no longer being used.
WordPress can release a security update.
It cannot climb out of the dashboard and force you to install it.
It cannot remove the plugin nobody remembers buying.
It cannot stop someone from giving six contractors administrator accounts.
It cannot prevent a business owner from ignoring seventeen update warnings for nine months because “the website is working fine.”
The platform can provide secure software and useful controls. The final result still depends on what people do with them.
Terrible news for anyone hoping the monthly subscription included adult supervision.
The integration nobody remembers is still invited to the party
SaaS products rarely stay neatly isolated.
They get connected to payment processors, calendars, email platforms, automation tools, spreadsheets, analytics services, form builders and other SaaS products.
Every integration creates another relationship that needs to be understood.
What can it access?
Can it only read data, or can it change and delete things too?
Who authorised it?
Does it still need access?
What happens if that service is compromised?
Does disconnecting a former team member also revoke the integrations and tokens they created?
The NCSC’s current guidance for using SaaS securely specifically recommends keeping track of integrations and service identities, including what permissions they have, who authorised them and when they were last used.
That is considerably less exciting than installing another automation.
It is also part of running the system properly.
A compliance badge is not a force field
Compliance reports and security certifications matter. They provide useful information about how a company manages its systems.
What they do not provide is a promise that the company will never be hacked.
In simple terms, a SOC 2 assessment examines the security controls a company says it has.
An auditor looks at questions such as:
- Who can access sensitive systems?
- How is that access controlled?
- Are important actions logged?
- Are risks and security incidents handled through documented processes?
- Are the controls operating as described?
For a Type II report, the auditor examines evidence from a period of time rather than only looking at the system on one particular day.
That is valuable.
It is still not the same as an auditor announcing, “Nobody will ever find a vulnerability in this software.”
No serious auditor could promise that.
A company can pass a SOC 2 assessment and later suffer a security incident. That does not automatically mean the assessment was fraudulent. It means SOC 2 never meant “unhackable” in the first place.
The official framework even accounts for controls that customers are expected to perform themselves. These are called “complementary user entity controls,” because apparently “things the customer still needs to do” was not impressive enough.
The AICPA describes SOC reports as information customers can use to assess and address the risks involved in outsourcing services.
Notice the wording.
Assess and address the risks.
Not print the logo, add it to the footer and declare cybersecurity finished.
A SOC 2 badge tells you something useful about a provider’s controls. It does not tell you that every feature is free of vulnerabilities, every employee will make the right decision, every future update will be safe or every customer account has been configured properly.
The provider may have excellent internal controls. You can still have excessive permissions, weak account recovery, unnecessary integrations and twelve administrators who all insist they need full access.
The certification does not follow your team around slapping reused passwords out of their hands.
SaaS can also fail on the provider’s side
Shared responsibility does not mean the provider is incapable of causing a problem.
A SaaS company can suffer a breach, an outage, a bad software update, a compromised employee account or a failure somewhere in its supply chain.
When your business depends entirely on one platform, its problems can become your problems very quickly.
That does not make SaaS a bad choice. It means you should know what happens if your chosen platform becomes unavailable tomorrow morning.
Can you export your data?
Do you have a recent copy?
Could you contact your customers without the platform?
Do you know which parts of the business would stop?
Could you move somewhere else, or has every process become dependent on one vendor?
Businesses love discussing onboarding because that is when everyone is excited.
Ask about leaving too.
Buying software changes the responsibility
It does not remove it.
With custom software, your development team is responsible for maintaining the application and making sound technical decisions.
With SaaS, more of the technical responsibility moves to the provider.
Your users, permissions, integrations, data handling and backup plans remain your responsibility.
You just have a different list of things that can go wrong.
Sometimes SaaS is safer.
Sometimes custom software is safer.
Sometimes the safest option is using SaaS for one part of the business and custom software for the parts where the available products are a terrible fit.
The correct answer depends on the data, the risk, the people involved and how the system will actually be used.
Ask better questions before buying
Before choosing a platform, ask:
- What information will we store in it?
- Who genuinely needs administrator access?
- Can we require multi-factor authentication?
- Can permissions be limited by role, client or responsibility?
- How will we remove access when somebody leaves?
- Which integrations will have access to our data?
- Can we see useful activity and security logs?
- How do we export and back up important information?
- What happens during an outage or security incident?
- How difficult would it be to leave the platform?
If the answer is a row of compliance logos and no explanation of who can export your customer database, keep asking.
The subscription is not the security plan
A SaaS subscription can remove a great deal of technical work from your business. That is one of the main reasons to buy one.
It can also introduce a new company, new integrations, new accounts and new places for your data to end up.
What it cannot remove is the need for somebody competent to configure it, manage access, review integrations, protect the data and notice when something looks wrong.
Buying SaaS changes the division of labour; it does not make your customer data somebody else’s problem.
The dangerous part is assuming it does.