Why "They're a Big Company" Isn't A Security Strategy

Why “They’re A Big Company” Isn’t A Security Strategy

Medtronic, a medical technology company. Instructure, an online education platform. Nike, an international apparel and lifestyle brand. On the surface, these organizations appear unrelated. Yet in 2026, each suffered a security incident that resulted in the exposure of significant amounts of data.

All three are large, multinational enterprises with budgets—and brand recognition—to match. It’s reasonable to assume they have access to the tools, talent, and resources necessary to secure their environments. In fact, in the case of some of these companies, they operate under strict regulatory regimes that mandate specific security controls.

This article is not an exploration of the root causes of those incidents. That analysis matters, but it belongs elsewhere. Instead, we’re continuing our focus on third‑party vendors—and what it actually means to manage risk when critical services sit outside your direct control.

It’s tempting to stop the conversation with, “They’re a big company,” and treat that as due diligence. But size is not a control, reputation is not a safeguard, and trust—by itself—is not a strategy. Relying on any of those is not risk management; it’s hope.

Why Trust Isn’t A Security Strategy

To better understand what’s happening when we place our trust in a company because it’s large, we need to clarify what it is we are actually trusting. One key item to understand: security isn’t executed by logos. When you trust a company, you are trusting that the people working at the company are operating with the correct intentions. In a perfect world, security controls would be absolute and everyone would follow them perfectly, but businesses often balance security controls with operational needs.

• Product managers have deadlines that need to be met
• Engineers have mandates to meet uptime requirements
• Executives look at growth and cost, not security

Nobody within a company is deliberately ignoring security requirements, but the reality is that security decisions are routinely negotiated against revenue pressures, availability guarantees, and delivery timelines. These trade-offs are not inherently malicious, they’re just an expected reality in large organizations, but they are precisely why trust alone cannot carry risk.

“The company” doesn’t accept or reject risk, individuals do.

Why Compliance And Certification Are Not Security

Large organizations are subject to a number of regulatory requirements that mandate security controls and audit processes. FERPA, HIPAA, SOX, and others all contain language mandating specific security controls within an organization to remain compliant. The problem is that the audits that verify compliance are not ongoing, but a snapshot in time.

Let’s look a little closer at what audits actually verify:

• Documented controls exist
• Policies are written
• Evidence was available at the time of review

Audits do not verify that controls are correctly scoped or enforced consistently. They do not ensure that access matches current operational reality. Compliance audits confirm intent, not real-time protection.

Environments are constantly changing in response to new systems integrations, emergency situations, platform updates, or even mergers or layoffs. These changes often outpace audit cadences, which are generally performed annually or six months at most. During the gaps between audits, new systems are brought online, changes are made to existing infrastructure, new security vulnerabilities are discovered by security research groups, or any number of other operational environment changes.

Additionally, compliance audits generally carry a specific scope and do not evaluate the environment as a whole. They look at specific systems and compare practices against specific controls. There are systems that are frequently deemed to be outside the scope of an audit. Proof of regulatory compliance is a strong indicator that a company takes security seriously, but these gaps are enough that you cannot equate compliance with security. More importantly, compliance does not tell you how much damage their failure will cause within your own organization.

What Happens When Things Go Wrong

Large organizations that provide a service to other companies frequently become a target for criminal activity precisely because their failure would have such a far reaching impact. For instance, Instructure’s breach in April/May of 2026 resulted in over 9,000 educational institutions losing access to their online learning platform, significantly hindering their operations. Past outages with Microsoft (not security related) have resulted in degraded services for tens of thousands of customers.

The question that must be asked when making the decision to partner with a third party provider is clear: “What can I do to keep operating when things go wrong?” As an education provider, do you have alternative means of contacting your students and keeping classes on their scheduled meeting times? If something goes wrong with your email provider, do you have backups of your mailboxes or an alternative means of receiving emails?

Failures happen, and large companies often do take responsibility, but your customers don’t care. What they see is that something they are expecting you to provide isn’t working the way that it’s supposed to. How do you ensure that the impact to your customers is minimized in the event of a problem?

Protecting Your Organization

We’ve said it before, but it’s worth repeating. Outsourcing function does not outsource responsibility. When things go wrong – and they will – it is your organization that must be ready to deal with the fallout. So what can we do to ensure that the damage is minimized when our vendors suffer a problem?

Minimize third party access to limit the damage radius in the event of a security incident. Ensure that integrations between your systems and those of a vendor are only what are required for functionality. Third party providers should not be granted full administrative access into your systems. This ensures that the damage that can be done to your own systems is limited to those controlled or influenced by the vendor.

Develop and test a business continuity plan to ensure your operations can continue, even if in a degraded condition, until vendor functionality is restored. Take the time while things are working correctly to establish a plan in the event of systems failure. If you prepare ahead of time, you reduce the risk of operational dependency that so many companies fall victim to. You don’t have to do this alone, either. Talk to your vendor about what a failure might look like and how you can minimize the impact to your own systems.

Ask the right questions before implementation so that your team can prepare for any accepted risk or seek out an alternate vendor if the risks are too great. While you are deciding on a vendor to supply a functional solution to your organization, take the time to ask them about past incidents, both security and operational, and what they did to get things back online quickly and effectively. Ask to see copies of their most recent compliance audits. More importantly, ask them bluntly what they are doing to ensure their own employees are following security requirements.

You’re Not Alone

In light of so many new reports of security incidents and functional problems that companies have faced in recent years, it can be easy to feel overwhelmed. How do you know which vendors are taking the right precautions? Are their security goals aligned with your own? How much access should you give them? It’s a lot to ask, and for small businesses, it can quickly become too much to handle alone.

Utah Tech Repair has experience working through these questions and more. We provide you with resources to help you meet your operational needs while remaining clear-eyed about downtime, dependency, and security risk. When you choose to work with us, you gain access to:

• Professionals experienced in systems integration and dependency analysis
• Context on commonly used third party providers and their operational patterns
• Support during vendor discussions to clarify expectations and boundaries
• Advocates willing to engage vendors directly when accountability matters

Ultimately, responsibility remains with you and your organization, even when third party vendors are engaged to provide needed functionality. If you want help navigating that journey, Utah Tech Repair is available.