2026 Security Resolutions: Fewer Assumptions, More Evidence

Security failures rarely come from missing controls. They come from assumptions that hardened into policy and stopped being questioned. Risk emerges from access and data decisions made over time, through role changes, project work, access sharing, temporary exceptions, and system evolution, that quietly persist long after their original purpose has faded.

As organizations look ahead to 2026, the most valuable security resolutions are not about adding tools or tightening rules. They’re about replacing belief with evidence.

Here are five resolutions that force uncomfortable, but necessary, conversations.

1. Stop Treating Access as a Binary Decision

The problem is familiar. Your IAM system shows that Sarah has read access to the finance database. What it doesn’t show is that she hasn’t logged in since October 2024, when she moved from Finance to Engineering.

Access accumulates quietly through role changes, project work, access sharing, temporary exceptions, and system migrations. Usage, meanwhile, changes constantly. Over time, the gap between what people can access and what they actually use grows in predictable ways.

This shows up everywhere:

• A contractor completes a six-month project, but their cloud role remains active.

• Temporary admin rights granted during an incident are never revoked.

• An acquisition brings in hundreds of users, and legacy access patterns are simply carried over.

Resolution: Instrument your systems to show when access was last exercised, not just when it was granted. Set a threshold, 90 days, 120 days, and require justification beyond it.

2. Admit That “Just in Case” Is a Risk Strategy

Many security decisions are framed as cautious:

• “Keep their access in case they’re needed during the transition.”

• “Retain this data in case Legal asks for it.”

• “Leave that service account enabled in case something breaks.”

These are not neutral choices. They are deliberate risk trades, hypothetical future convenience exchanged for real, present exposure.

This pattern appears repeatedly in major breaches. Attackers often succeed not because they create new access, but because unnecessary access already exists.

Resolution: When you keep access or data “just in case,” write down what scenario you’re protecting against, and what risk you’re accepting. Revisit that decision quarterly.

3. Measure What Moves, Not What Exists

Many security dashboards still emphasize inventory, reflecting a posture-management approach that addressed yesterday’s visibility challenges more than today’s risk questions:

• 12,847 users

• 2,341 applications

• 487 policies

These numbers describe scale, not risk.

Risk shows up in behavior:

• A database administrator querying customer SSNs at 2 a.m. on a Sunday

• An object store accessed once after creation, then never again

• A service account suddenly authenticating from a new geography

• A contractor downloading ten times more data in their final week than during their entire tenure

Resolution: Identify three behavioral anomalies that would meaningfully indicate compromise or policy drift in your environment. Build detection for them. Review the results monthly and refine over time.

4. Accept That Reviews Without Context Are Procedural

Every quarter, a familiar message lands in a manager’s inbox:

“Please review and approve the following access for your team members:
– John Smith: SalesDB_Read, SalesDB_Write, CRM_Admin, Reports_View…”

The manager doesn’t know what John actually uses. Approval becomes the path of least resistance. Compliance is documented and risk is unchanged.

Reviews become useful only when they include context:

• John used SalesDB_Read 847 times last quarter: clearly needed.

• John used CRM_Admin twice in the past year: investigate.

• John has never used Reports_View: remove.

Resolution: Don’t run access reviews without usage data. If you can’t provide it, be honest about what you’re performing: compliance theater, not risk management.

5. Design Security for Change, Not Control

Most security architectures quietly assume:

• Data stays in approved systems.

• Employees work from known locations.

• Applications flow through sanctioned pipelines.

• Roles remain stable.

None of these assumptions hold for long.

What actually happens:

• Marketing adopts a new analytics tool before the security team hears about it.

• The CEO needs VPN access from a hotel Wi-Fi network in Portugal.

• Engineering spins up a shadow CI/CD pipeline because the official one is too slow.

• A reorganization changes reporting lines for a large portion of the company.

Controls built for static environments don’t fail gracefully. They generate exceptions, workarounds, and shadow IT, all in the name of preserving control.

Resolution: For every security control, ask: What breaks when the underlying assumption changes? Then build monitoring that detects the change, not just enforcement that tries to prevent it.

What Actually Changes Behavior

Most organizations already have:

• Zero Trust frameworks they reference

• Regular access reviews they run

• Audit logs they collect

• Policies they publish

What’s missing isn’t more controls. It’s the evidence that makes decisions obvious:

• “This access hasn’t been used in six months” → remove it.

• “This data was accessed at an unusual time” → investigate it.

• “This approval has no business justification” → challenge it.

None of this is easy. Acting on evidence often means questioning long-standing assumptions and having conversations people would rather avoid.

That’s also where risk actually gets reduced.

Start Somewhere

Pick one resolution. Apply it to one system or one team. Measure what changes.

The goal isn’t perfection. It’s replacing “we’ve always done it this way” with “here’s what’s actually happening.”

Which assumption in your security program would be the most uncomfortable to test with real evidence?