A Baseline, Not a Guarantee

When evaluating a new cloud or software-as-a-service (SaaS) tool, seeing a SOC 2 or ISO 27001 badge gives leadership immediate peace of mind. It provides independent verification that the vendor’s internal control environment and hosting infrastructure have been assessed against recognised standards.

However, organisations routinely mistake vendor compliance for operational security.

A third-party certification confirms that the vendor’s infrastructure is protected. It says nothing about how your internal team has configured the platform, who holds administrative access, or how sensitive data inside the system is being shared.

Under the cloud shared responsibility model, certification is a baseline, not an assurance. The vendor secures the underlying software, but the operational responsibility for configuration, identity management, and daily use remains entirely with you.

​​

The Compliance vs. Security Gap

The distinction between vendor compliance and customer implementation is where real-world exposure sits.

​

Independent audits assess the controls built into the product. They do not evaluate how your business actually deploys or operates the product in daily workflows. The gap between "the tool has security controls" and "we are using the tool securely" is where breaches consistently occur

​

Vendor Obligations

• Core infrastructure security

• Platform software patches

• Data centre controls

​

Customer Responsibility

• Access permissions & MFA

• Sharing & privacy settings

• Audit logging & monitoring

​

When an organisation assumes that buying a certified tool automatically makes their operations secure, critical implementation details get overlooked.

​

Why Certified Platforms Still Experience Breaches

 

This implementation gap is not a theoretical problem.

Market-leading platforms such as Microsoft 365, Google Workspace, Slack, and Atlassian Cloud all hold top-tier external certifications. Yet each of these platforms has been involved in high-profile security incidents. In the vast majority of cases, the root cause was not a breakdown of the vendor’s infrastructure. The contributing factors were customer-side misconfigurations and identity errors
 

• Over-permissioned service accounts: Non-human service principles and API keys created with broad administrative rights, often left hardcoded in public code repositories.

• Exposed SharePoint sites: Cloud storage spaces left with permissive default configurations, allowing sensitive corporate files to be accessed externally.

• Secrets left in Slack channels: API keys, database credentials, and operational passwords shared casually in communication channels without expiry or masking.

• Unmonitored Atlassian instances: Cloud work management environments configured with excessive user privileges and audit logging disabled

In every single instance, the vendor met its security obligations. The customer's configuration and implementation did not.

​

The Second Blind Spot: Continuous Vendor Risk

​

Configuration drift is not the only risk that certifications hide. A compliance report represents a single point in time, whereas vendor and supply chain risks are continuous.

​

A certification audit tells you what a vendor looked like on the day the auditor examined them. It cannot tell you what will happen to that vendor over the next twelve months.

​

A vendor holding an active certificate today could easily:

​

• Be acquired by an organization with weaker privacy standards and looser controls

• Be withdrawn from the market or shut down within a year

• Transfer customer data to foreign jurisdictions with limited legal protections

• Be purchased by a firm with a documented history of unresolved security incidents

​

Relying on an annual certificate leaves leadership blind to changes in vendor ownership, commercial stability, and engineering roadmaps.

​

Three Practical Steps to Close the Implementation Gap

​

Because cloud providers have fulfilled their obligations, protecting your organizational data requires proactive governance.

​

Here are three practical steps security and IT teams should take to secure their SaaS footprint:

​

1. Maintain a Complete Application Inventory
You cannot secure what you do not know exists. Conduct regular discovery across your organisation to map every SaaS tool currently in use including sanctioned enterprise platforms and unsanctioned tools adopted by individual departments on company credit cards

2. Build Configuration Controls into Initial Design
Security settings should never be an afterthought applied months after rollout. Essential controls must be configured before systems go live

• Enforce Multi-Factor Authentication (MFA) across all users and admin accounts

• Apply strict least-privilege access, ensuring users and integrations only access what is necessary for their job

• Enable and centralize audit logging to track unusual data downloads or permission changes

• Implement data classification to restrict open sharing of confidential information

​

3. Re-Audit on a Defined Cycle
Software configuration is not static. Over time, staff change roles, temporary permissions become permanent, and new integrations are connected. Establish a regular review rhythm aligned with your risk profile to validate access permissions, revoke unused accounts, and correct configuration drift.

​

Moving Beyond Box-Ticking

​

Independent security certifications are valuable procurement baselines, but they are never a substitute for hands-on security governance.

​

If your organisation wants to close the implementation gap rather than simply tick a compliance box, the senior practitioner team at CyberCure can help review your cloud environments, identity permissions, and SaaS configurations.

​