Security basics: reading authentication, authorization, and encryption as business risk
Most security incidents don’t come from sophisticated technical attacks. They come from basic misconfigurations left unaddressed: overly permissive access, passwords stored in plain text, patches that were never applied. Trace almost any breach back far enough and you land on one of these unglamorous gaps.
Non-technical M&A staff, VC investors, and SME owners don’t need to understand the implementation details of security systems. But understanding three core concepts — authentication, authorization, and encryption — and what happens in business terms when each one fails is essential for investment decisions and for any company rolling out AI tools internally. This piece walks through those three concepts, the failure patterns that lead to real incidents, and the minimum set of questions a non-technical leader should be able to answer.
Authentication, authorization, and encryption: three concepts, three kinds of risk
Security discussions become much clearer once you separate three concepts that sound similar but protect entirely different things: authentication, authorization, and encryption.
Authentication answers “who are you?” It covers ID/password logins, fingerprint scans, and SMS verification codes. When authentication is broken, an attacker impersonates a legitimate user and walks straight into the system. A common attack pattern today is “credential stuffing”: attackers take ID/password pairs leaked from one breached service and try them against other services, betting that people reuse passwords. Companies without multi-factor authentication (MFA — requiring something beyond a password, such as a code sent to a phone) are particularly exposed to this.
Authorization answers “what are you allowed to do?” Once a user’s identity is confirmed, authorization determines which data they can access and which actions they can take. Authentication and authorization are independent, and it’s common to see companies where identity checks are solid but permissions are wildly over-provisioned: a former employee’s account that was never deactivated, or an entire staff roster with read access to the finance system. These are authorization failures, not authentication failures.
Encryption converts data into a form third parties can’t read. There are two flavors: encryption “at rest” (data sitting in a database or storage) and encryption “in transit” (data moving between systems). TLS — the technology behind https:// in a browser’s address bar — is the standard for in-transit encryption. Data that isn’t encrypted is fully readable the moment access controls are bypassed.
Because these three layers are independent, hardening only one accomplishes little. A company can roll out MFA (strong authentication) and still suffer a major breach if every employee can read every customer record (weak authorization) — a compromised or stolen account then exposes everything, MFA notwithstanding.
Common incident patterns and the technical gaps behind them
Security headlines sound technical, but the root causes usually fall into a handful of recurring patterns.
1. Leaked or reused credentials
The most common pattern: credentials leaked from one breach get reused to log into other services. When employees reuse the same password across multiple tools, a single leak anywhere becomes a company-wide exposure. MFA and a password manager are the two highest-leverage countermeasures here.
2. Over-provisioned or stale permissions
Former employees whose accounts were never deactivated, contractors given far more access than their work requires, or the same credentials reused across development and production environments — these are operational failures, not sophisticated exploits. OWASP’s Top 10 list of web application risks repeatedly ranks “Broken Access Control” near the top (see OWASP Top 10). The technical fix is usually simple; the harder part is having a process that enforces it consistently.
3. Unpatched, publicly known vulnerabilities
When a software vulnerability is disclosed, a fix is typically released alongside it. Systems that don’t apply patches promptly remain exposed to attack techniques that are already public knowledge. The 2017 WannaCry ransomware outbreak, which caused global damage, exploited a vulnerability for which a patch had already been available for months. For non-technical readers, the key takeaway is simple: known, unpatched holes cause more real-world damage than novel attack techniques.
4. Supply-chain compromise
A company’s own systems can be solid while a vendor, contractor, or an open-source library it depends on gets compromised — and the breach spreads through that connection. Recent incidents increasingly target suppliers and integration partners rather than the primary target directly. As SMEs adopt more AI tools and connect more external APIs, the number of these indirect entry points grows too.
The minimum checklist for a non-technical leader
You don’t need to understand implementation details, but a leader involved in investment decisions or internal AI rollout should be able to answer four questions.
| Item | Question to ask | Reasonable benchmark |
|---|---|---|
| Access management | How quickly are departed or transferred employees’ accounts deactivated? | Same day to within one week |
| Backups | How often is data backed up, and when was a restore last actually tested? | Regular backups, plus a restore test at least once a year |
| Patch operations | How many days, on average, pass between a critical vulnerability’s disclosure and its patch being applied internally? | Days to two weeks for high-severity issues |
| Logging | Can the company trace who accessed what data, and when, after the fact? | Access logs retained for core systems |
If a leader can’t answer these four questions without asking someone else, that’s a signal the security operation is undocumented and dependent on one or two individuals. What matters here isn’t technical sophistication — it’s whether the operation is visible and repeatable.
In an investment or acquisition due diligence process, these items form part of the checks covered in Technical due diligence: the full picture and seven evaluation axes. Before signing a contract with a SaaS vendor in particular, checking for third-party certifications like SOC 2 or ISO 27001 — and the scope they cover — reduces the verification burden on your own side.
How much should a company spend on security?
There’s no universal formula for the right security budget, but three principles help frame the decision.
First, spend in proportion to how sensitive the data is. A business handling personal data, payment information, or health records should invest more than one handling low-sensitivity information. Pouring resources into elaborate defenses for a service that holds nothing sensitive isn’t a good use of scarce budget.
Second, weigh the cost of a likely incident against the cost of prevention. A data breach triggers investigation costs, customer notification costs, reputational damage that drives churn, and in some cases regulatory exposure. The baseline measures — MFA, cleaned-up permissions, a documented patch process — are relatively cheap to implement and deliver a high return relative to their cost. More elaborate investments, like dedicated threat-detection systems, make sense once a company’s scale and data sensitivity clear a certain threshold, not before.
Third, treat security spending as an ongoing operating cost, not a one-time purchase. Buying a tool doesn’t help if nobody continues applying patches or auditing permissions. The same gap SMEs run into with AI adoption — “we don’t have anyone in-house who understands this” — applies just as directly to security: without someone accountable for keeping the operation running, it degrades over time even after a good initial setup.
Where this connects to due diligence and AI adoption
This basic understanding of security pays off directly in two situations.
In investment and acquisition due diligence, weak security operations are exactly the kind of issue that surfaces after closing, as covered in Ten technical risks that surface after investment. Checking the four items above — access management, backups, patch operations, logging — surfaces much of the risk that surface-level questions miss.
For SMEs rolling out AI tools, connecting internal data to external AI services requires deciding, up front, how access control and data handling will work. Deferring permission design because a tool is convenient risks exposing sensitive information beyond its intended scope. Security fundamentals are a question worth settling at the start of an AI rollout, not after.
If you’d like to review your current security operations, or want a second opinion on security-related risks before an investment or acquisition, get in touch. Tied also offers hands-on support for SMEs adopting AI through TiedWorkspace, and technical due diligence support for investors and corporates through TiedPro for investors and TiedPro for startups.
Related reading
Security is closely tied to infrastructure choice. Cloud services explained: reading AWS, GCP, and Azure as business decisions covers compliance certifications as part of the cloud-selection evaluation.
For the full set of technical due diligence questions, see The complete technical due diligence checklist for investors. For how these risks accumulate as tech debt more broadly, see What technical debt actually is: a redefinition for investors and executives.