Cardwell started her career at Netscape, become a VP of engineering at American Express, CISO at UnitedHealth Group, and now CISO in Residence at Transcend.
The post CISO Conversations: Aimee Cardwell appeared first on SecurityWeek.
To implement effective cybersecurity programs and keep the security team deeply integrated into all business processes, the CISO needs to regularly demonstrate the value of this work to senior management. This requires speaking the language of business, but a dangerous trap awaits those who try. Security professionals and executives often use the same words, but for entirely different things. Sometimes, a number of similar terms are used interchangeably. As a result, top management may not understand which threats the security team is trying to mitigate, what the company’s actual level of cyber-resilience is, or where budget and resources are being allocated. Therefore, before presenting sleek dashboards or calculating the ROI of security programs, it’s worth subtly clarifying these important terminological nuances.
By clarifying these terms and building a shared vocabulary, the CISO and the Board can significantly improve communication and, ultimately, strengthen the organization’s overall security posture.
Varying interpretations of terms are more than just an inconvenience; the consequences can be quite substantial. A lack of clarity regarding details can lead to:
Many executives believe that cybersecurity is a purely technical issue they can hand off to IT. Even though the importance of cybersecurity to business is indisputable, and cyber-incidents have long ranked as a top business risk, surveys show that many organizations still fail to engage non-technical leaders in cybersecurity discussions.
Information security risks are often lumped in with IT concerns like uptime and service availability. In reality, cyberrisk is a strategic business risk linked to business continuity, financial loss, and reputational damage.
IT risks are generally operational in nature, affecting efficiency, reliability, and cost management. Responding to IT incidents is often handled entirely by IT staff. Major cybersecurity incidents, however, have a much broader scope; they require the engagement of nearly every department, and have a long-term impact on the organization in many ways — including as regards reputation, regulatory compliance, customer relationships, and overall financial health.
Cybersecurity is integrated into regulatory requirements at every level — from international directives like NIS2 and GDPR, to cross-border industry guidelines like PCI DSS, plus specific departmental mandates. As a result, company management often views cybersecurity measures as compliance checkboxes, believing that once regulatory requirements are met, cybersecurity issues can be considered resolved. This mindset can stem from a conscious effort to minimize security spending (“we’re not doing more than what we’re required to”) or from a sincere misunderstanding (“we’ve passed an ISO 27001 audit, so we’re unhackable”).
In reality, compliance is meeting the minimum requirements of auditors and government regulators at a specific point in time. Unfortunately, the history of large-scale cyberattacks on major organizations proves that “minimum” requirements have that name for a reason. For real protection against modern cyberthreats, companies must continuously improve their security strategies and measures according to the specific needs of the given industry.
These three terms are often used synonymously, which leads to erroneous conclusions made by management: “There’s a critical vulnerability on our server? That means we have a critical risk!” To avoid panic or, conversely, inaction, it’s vital to use these terms precisely and understand how they relate to one another.
A vulnerability is a weakness — an “open door”. This could be a flaw in software code, a misconfigured server, an unlocked server room, or an employee who opens every email attachment.
A threat is a potential cause of an incident. This could be a malicious actor, malware, or even a natural disaster. A threat is what might “walk through that open door”.
Risk is the potential loss. It’s the cumulative assessment of the likelihood of a successful attack, and what the organization stands to lose as a result (the impact).
The connections among these elements are best explained with a simple formula:
Risk = (Threat × Vulnerability) × Impact
This can be illustrated as follows. Imagine a critical vulnerability with a maximum severity rating is discovered in an outdated system. However, this system is disconnected from all networks, sits in an isolated room, and is handled by only three vetted employees. The probability of an attacker reaching it is near zero. Meanwhile, the lack of two-factor authentication in the accounting systems creates a real, high risk, resulting from both a high probability of attack and significant potential damage.
Management’s perception of security crises is often oversimplified: “If we get hit by ransomware, we’ll just activate the IT Disaster Recovery plan and restore from backups”. However, conflating these concepts — and processes — is extremely dangerous.
Incident Response (IR) is the responsibility of the security team or specialist contractors. Their job is to localize the threat, kick the attacker out of the network, and stop the attack from spreading.
Disaster Recovery (DR) is an IT engineering task. It’s the process of restoring servers and data from backups after the incident response has been completed.
Business Continuity (BC) is a strategic task for top management. It’s the plan for how the company continues to serve customers, ship goods, pay compensation, and talk to the press while its primary systems are still offline.
If management focuses solely on recovery, the company will lack an action plan for the most critical period of downtime.
Leaders at all levels sometimes assume that simply conducting security training guarantees results: “The employees have passed their annual test, so now they won’t click on a phishing link”. Unfortunately, relying solely on training organized by HR and IT won’t cut it. Effectiveness requires changing the team’s behavior, which is impossible without the engagement of business management.
Awareness is knowledge. An employee knows what phishing is and understands the importance of complex passwords.
Security culture refers to behavioral patterns. It’s what an employee does in a stressful situation or when no one’s watching. Culture isn’t shaped by tests, but by an environment where it’s safe to report mistakes and where it’s customary to identify and prevent potentially dangerous situations. If an employee fears punishment, they’ll hide an incident. In a healthy culture, they’ll report a suspicious email to the SOC, or nudge a colleague who forgets to lock their computer, thereby becoming an active link in the defense chain.
Business leaders often think in outdated “fortress wall” categories: “We bought expensive protection systems, so there should be no way to hack us. If an incident occurs, it means the CISO failed”. In practice, preventing 100% of attacks is technically impossible and economically prohibitive. Modern strategy is built on a balance between cybersecurity and business effectiveness. In a balanced system, components focused on threat detection and prevention work in tandem.
Prevention deflects automated, mass attacks.
Detection and Response help identify and neutralize more professional, targeted attacks that manage to bypass prevention tools or exploit vulnerabilities.
The key objective of the cybersecurity team today isn’t to guarantee total invulnerability, but to detect an attack at an early stage and minimize the impact on the business. To measure success here, the industry typically uses metrics like Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).
The zero trust concept — which implies “never trust, always verify” for all components of IT infrastructure — has long been recognized as relevant and effective in corporate security. It requires constant verification of identity (user accounts, devices, and services) and context for every access request based on the assumption that the network has already been compromised.
However, the presence of “zero trust” in the name of a security solution doesn’t mean an organization can adopt this approach overnight simply by purchasing the product.
Zero trust isn’t a product you can “turn on”; it’s an architectural strategy and a long-term transformation journey. Implementing zero trust requires restructuring access processes and refining IT systems to ensure continuous verification of identity and devices. Buying software without changing processes won’t have a significant effect.
When migrating IT services to cloud infrastructure like AWS or Azure, there’s often an illusion of a total risk transfer: “We pay the provider, so security is now their headache”. This is a dangerous misconception, and a misinterpretation of what is known as the Shared Responsibility Model.
Security of the cloud is the provider’s responsibility. It protects the data centers, the physical servers, and the cabling.
Security in the cloud is the client’s responsibility.
Discussions regarding budgets for cloud projects and their security aspects should be accompanied by real life examples. The provider protects the database from unauthorized access according to the settings configured by the client’s employees. If employees leave a database open or use weak passwords, and if two-factor authentication isn’t enabled for the administrator panel, the provider can’t prevent unauthorized individuals from downloading the information — an all-too-common news story. Therefore, the budget for these projects must account for cloud security tools and configuration management on the company side.
Leaders often confuse automated checks, which fall under cyber-hygiene, with assessing IT assets for resilience against sophisticated attacks: “Why pay hackers for a pentest when we run the scanner every week?”
Vulnerability scanning checks a specific list of IT assets for known vulnerabilities. To put it simply, it’s like a security guard doing the rounds to check that the office windows and doors are locked.
Penetration testing (pentesting) is a manual assessment to evaluate the possibility of a real-world breach by exploiting vulnerabilities. To continue the analogy, it’s like hiring an expert burglar to actually try and break into the office.
One doesn’t replace the other; to understand its true security posture, a business needs both tools.
A common and dangerous misconception concerns the scope of protection and the overall visibility held by IT and Security. A common refrain at meetings is, “We have an accurate inventory list of our hardware. We’re protecting everything we own”.
Managed IT assets are things the IT department has purchased, configured, and can see in their reports.
An attack surface is anything accessible to attackers: any potential entry point into the company. This includes Shadow IT (cloud services, personal messaging apps, test servers…), which is basically anything employees launch themselves in circumvention of official protocols to speed up or simplify their work. Often, it’s these “invisible” assets that become the entry point for an attack, as the security team can’t protect what it doesn’t know exists.
For years, security leaders have lived with an uncomfortable truth. It has been to date, simply impossible to investigate every alert. As alert volumes exploded and teams failed to scale, SOCs, whether in-house or outsourced, normalized “acceptable risk” with the deprioritization of low-severity and informational alerts.
Our latest research shows that this approach is no longer defensible.
Intezer has just released the 2026 AI SOC Report for CISOs, based on the forensic analysis of more than 25 million security alerts across live enterprise environments. The findings reveal a critical disconnect between how security teams prioritize alerts and where real threats actually originate, and the cost of that gap is far higher than most organizations realize .
Across endpoint, cloud, identity, network, and phishing telemetry, Intezer found that nearly 1% of confirmed incidents originated from alerts initially labeled as low-severity or informational. On endpoints, that figure climbed to nearly 2%.
At enterprise scale, that percentage is not noise.
For a typical organization generating roughly 450,000 alerts per year, this translates to ~50 real threats annually, about one per week, never investigated by a SOC or MDR team. These are not theoretical risks. They are real compromises hiding in plain sight, dismissed not because they were benign, but because teams lacked the capacity to look.
Because Intezer AI SOC investigates 100% of alerts using forensic-grade analysis, the report exposes how attackers actually operate once you remove triage bias from the equation.
More than half of endpoint alerts were not automatically mitigated by endpoint protection tools. Of those, nearly 9% were confirmed malicious. Even more concerning, 1.6% of endpoints undergoing live forensic scans were still actively compromised despite being reported as “mitigated” by EDR tools.
See the full endpoint threat data → Download the 2026 AI SOC Report
Within endpoint alerts alone, 1.9% of low-severity and informational alerts were real incidents, the exact alerts most SOCs never review.
Cloud telemetry was dominated by defense evasion and persistence techniques, reflecting a shift toward long-term access, token abuse, and misuse of legitimate services rather than overt exploitation.
Fewer than 6% of malicious phishing emails contained attachments. Most relied on links, language, and abuse of legitimate services such as cloud file sharing, code sandboxes, CAPTCHA mechanisms, where traditional controls have limited visibility.
Most cloud posture findings stemmed from legacy or default configurations, especially in Amazon S3, including missing encryption, weak access controls, and lack of logging—issues often classified as “low severity,” yet repeatedly exploited once attackers gain a foothold.
To read the full report and all the findings, download the CISOs guide to AI SOC 2026 here.
Modern SOC failures are rarely the result of a single broken tool or negligent team. They are the outcome of structural tradeoffs that every traditional SOC—internal or MDR—has been forced to make.
Capacity is the first constraint.
Human analysts do not scale linearly with alert volume. As telemetry expands across endpoint, cloud, identity, network, and SaaS, SOCs hit a hard ceiling. The only way to cope is aggressive triage: close most alerts automatically, investigate only what looks “important,” and hope severity labels align with reality. The 2026 AI SOC Report shows that this assumption is false at scale.
Tool fragmentation compounds the problem.
Most SOC stacks are collections of siloed detections, EDR, SIEM, identity, cloud posture, email, each optimized for a narrow signal. Severity is assigned locally, without cross-surface context or forensic validation. As a result, alerts are scored based on abstract rules, not evidence of compromise. When SOCs trust these labels blindly, they inherit the tools’ blind spots.
Process tradeoffs lock risk in place.
Once triage rules are defined, they become institutionalized. Low-severity alerts are ignored by design. MDR providers codify this into SLAs. Internal SOCs bake it into runbooks. Crucially, there is no closed-loop feedback: missed threats do not automatically improve detections, because they were never investigated in the first place.
The outcome is not an occasional failure. It is systematic, repeatable risk, embedded directly into how SOCs operate.
The data in the 2026 AI SOC Report makes clear that missed threats are not exotic edge cases. They are ordinary attacks progressing quietly through environments because no one looked.
Endpoints marked “mitigated” but still compromised
In over 1.6% of live forensic endpoint scans, Intezer found active malicious code running in memory even though the EDR had already reported the threat as resolved. These cases included stealers, RATs, and post-exploitation frameworks, often originating from low-severity alerts that never triggered deeper inspection. Without memory-level forensics, these compromises would have remained invisible.
Phishing hosted on trusted platforms
Attackers increasingly host phishing pages on legitimate developer platforms like Vercel and CodePen, or abuse trusted cloud services such as OneDrive and PayPal. The parent domains appear reputable, so alerts are downgraded or ignored. Yet behind them are live credential-harvesting pages that bypass email gateways and browser-based defenses alike.
Cloud misconfigurations as delayed breach accelerators
Many cloud posture findings such as unencrypted S3 buckets, missing access logs and permissive cross-account policies rarely trigger action. But once an attacker gains any foothold, these long-standing misconfigurations dramatically accelerate lateral movement, persistence, and data exposure.
In every case, the failure was not detection. The signal existed. The failure was investigation.
Attackers understand SOC economics better than most defenders.
They know which alerts generate fatigue.
They know which detections are noisy.
They know which categories are deprioritized by default.
As a result, modern attackers design their campaigns to blend into the backlog, not trigger alarms.
Stealth over speed
Cloud intrusions favor defense evasion, persistence, and token abuse over loud exploitation. These behaviors generate alerts, but rarely high-severity ones. The report shows cloud telemetry dominated by exactly these tactics, indicating attackers are optimizing for long-term access rather than immediate impact.
Living off trusted infrastructure
Phishing campaigns increasingly abuse legitimate brands, file-sharing services, CAPTCHA frameworks, and developer platforms. These environments inherit trust by default, allowing attackers to operate under severity thresholds that SOCs routinely ignore.
Multi-stage loaders and memory-only execution
On endpoints, attackers rely on layered loaders, in-memory payloads, and obfuscation techniques that evade static detections. Initial alerts may look benign or incomplete. Without forensic follow-through, SOCs miss the actual compromise entirely.
Attackers are not evading detection systems alone, rather they are exploiting SOC decision-making models.
For CISOs and SOC leaders, the implication is stark:
Risk is no longer defined by what you detect, but by what you choose not to investigate.
If your SOC:
Then missed threats are not anomalies, they are guaranteed.
The organizations that will reduce risk in 2026 are not adding more dashboards or rewriting triage rules. They are adopting operating models where investigation is no longer a scarce resource.
This is why AI-driven, forensic-grade SOC platforms fundamentally change the equation. When every alert is investigated:
This is the shift behind the Intezer AI SOC model and why the concept of acceptable risk must be redefined for the modern threat landscape.
The data in the 2026 AI SOC Report points to a different reality, one where AI-driven forensic analysis removes investigation capacity as a constraint.
When every alert is investigated:
This is the operating model behind Intezer AI SOC, powered by ForensicAI™ and it is why the definition of acceptable risk must be reset.
The 2026 AI SOC Report for CISOs is grounded in:
All data was aggregated and anonymized across Intezer’s global enterprise customer base.
👉 Download the full report to explore the findings in detail, and
👉 Join Intezer’s research team on Wednesday, February 4th at 12 p.m. ET for a live webinar breaking down what this data means for SOC leaders and CISOs.
Because in 2026, the biggest risk is no longer what you detect, it’s what you choose not to investigate.
The post Alert fatigue is costing you: Why your SOC misses 1% of real threats appeared first on Intezer.
Millions of IT systems — some of them industrial and IoT — may start behaving unpredictably on January 19. Potential failures include: glitches in processing card payments; false alarms from security systems; incorrect operation of medical equipment; failures in automated lighting, heating, and water supply systems; and many more or less serious types of errors. The catch is — it will happen on January 19, 2038. Not that that’s a reason to relax — the time left to prepare may already be insufficient. The cause of this mass of problems will be an overflow in the integers storing date and time. While the root cause of the error is simple and clear, fixing it will require extensive and systematic efforts on every level — from governments and international bodies and down to organizations and private individuals.
The Unix epoch is the timekeeping system adopted by Unix operating systems, which became popular across the entire IT industry. It counts the seconds from 00:00:00 UTC on January 1, 1970, which is considered the zero point. Any given moment in time is represented as the number of seconds that have passed since that date. For dates before 1970, negative values are used. This approach was chosen by Unix developers for its simplicity — instead of storing the year, month, day, and time separately, only a single number is needed. This facilitates operations like sorting or calculating the interval between dates. Today, the Unix epoch is used far beyond Unix systems: in databases, programming languages, network protocols, and in smartphones running iOS and Android.
Initially, when Unix was developed, a decision was made to store time as a 32-bit signed integer. This allowed for representing a date range from roughly 1901 to 2038. The problem is that on January 19, 2038, at 03:14:07 UTC, this number will reach its maximum value (2,147,483,647 seconds) and overflow, becoming negative, and causing computers to “teleport” from January 2038 back to December 13, 1901. In some cases, however, shorter “time travel” might happen — to point zero, which is the year 1970.
This event, known as the “year 2038 problem”, “Epochalypse”, or “Y2K38”, could lead to failures in systems that still use 32-bit time representation — from POS terminals, embedded systems, and routers, to automobiles and industrial equipment. Modern systems solve this problem by using 64 bits to store time. This extends the date range to hundreds of billions of years into the future. However, millions of devices with 32-bit dates are still in operation, and will require updating or replacement before “day Y” arrives.
In this context, 32 and 64 bits refer specifically to the date storage format. Just because an operating system or processor is 32-bit or 64-bit, it doesn’t automatically mean it stores the date in its “native” bit format. Furthermore, many applications store dates in completely different ways, and might be immune to the Y2K38 problem, regardless of their bitness.
In cases where there’s no need to handle dates before 1970, the date is stored as an unsigned 32-bit integer. This type of number can represent dates from 1970 to 2106, so the problem will arrive in the more distant future.
The infamous year 2000 problem (Y2K) from the late 20th century was similar in that systems storing the year as two digits could mistake the new date for the year 1900. Both experts and the media feared a digital apocalypse, but in the end there were just numerous isolated manifestations that didn’t lead to global catastrophic failures.
The key difference between Y2K38 and Y2K is the scale of digitization in our lives. The number of systems that will need updating is way higher than the number of computers in the 20th century, and the count of daily tasks and processes managed by computers is beyond calculation. Meanwhile, the Y2K38 problem has already been, or will soon be, fixed in regular computers and operating systems with simple software updates. However, the microcomputers that manage air conditioners, elevators, pumps, door locks, and factory assembly lines could very well chug along for the next decade with outdated, Y2K38-vulnerable software versions.
The date’s rolling over to 1901 or 1970 will impact different systems in different ways. In some cases, like a lighting system programmed to turn on every day at 7pm, it might go completely unnoticed. In other systems that rely on complete and accurate timestamps, a full failure could occur — for example, in the year 2000, payment terminals and public transport turnstiles stopped working. Comical cases are also possible, like issuing a birth certificate with a date in 1901. Far worse would be the failure of critical systems, such as a complete shutdown of a heating system, or the failure of a bone marrow analysis system in a hospital.
Cryptography holds a special place in the Epochalypse. Another crucial difference between 2038 and 2000 is the ubiquitous use of encryption and digital signatures to protect all communications. Security certificates generally fail verification if the device’s date is incorrect. This means a vulnerable device would be cut off from most communications — even if its core business applications don’t have any code that incorrectly handles the date.
Unfortunately, the full spectrum of consequences can only be determined through controlled testing of all systems, with separate analysis of a potential cascade of failures.
IT and InfoSec teams should treat Y2K38 not as a simple software bug, but as a vulnerability that can lead to various failures, including denial of service. In some cases, it can even be exploited by malicious actors. To do this, they need the ability to manipulate the time on the targeted system. This is possible in at least two scenarios:
Exploitation of this error is most likely in OT and IoT systems, where vulnerabilities are traditionally slow to be patched, and the consequences of a failure can be far more substantial.
An example of an easily exploitable vulnerability related to time counting is CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) in Dover ProGauge MagLink LX4 automatic fuel-tank gauge consoles. Time manipulation can cause a denial of service at the gas station, and block access to the device’s web management panel. This defect earned its own CISA advisory.
The foundation for solving the Y2K38 problem has been successfully laid in major operating systems. The Linux kernel added support for 64-bit time even on 32-bit architectures starting with version 5.6 in 2020, and 64-bit Linux was always protected from this issue. The BSD family, macOS, and iOS use 64-bit time on all modern devices. All versions of Windows released in the 21st century aren’t susceptible to Y2K38.
The situation at the data storage and application level is far more complex. Modern file systems like ZFS, F2FS, NTFS, and ReFS were designed with 64-bit timestamps, while older systems like ext2 and ext3 remain vulnerable. Ext4 and XFS require specific flags to be enabled (extended inode for ext4, and bigtime for XFS), and might need offline conversion of existing filesystems. In the NFSv2 and NFSv3 protocols, the outdated time storage format persists. It’s a similar patchwork landscape in databases: the TIMESTAMP type in MySQL is fundamentally limited to the year 2038, and requires migration to DATETIME, while the standard timestamp types in PostgreSQL are safe. For applications written in C, pathways have been created to use 64-bit time on 32-bit architectures, but all projects require recompilation. Languages like Java, Python, and Go typically use types that avoid the overflow, but the safety of compiled projects depends on whether they interact with vulnerable libraries written in C.
A massive number of 32-bit systems, embedded devices, and applications remain vulnerable until they’re rebuilt and tested, and then have updates installed by all their users.
Various organizations and enthusiasts are trying to systematize information on this, but their efforts are fragmented. Consequently, there’s no “common Y2K38 vulnerability database” out there (1, 2, 3, 4, 5).
The methodologies created for prioritizing and fixing vulnerabilities are directly applicable to the year 2038 problem. The key challenge will be that no tool today can create an exhaustive list of vulnerable software and hardware. Therefore, it’s essential to update inventory of corporate IT assets, ensure that inventory is enriched with detailed information on firmware and installed software, and then systematically investigate the vulnerability question.
The list can be prioritized based on the criticality of business systems and the data on the technology stack each system is built on. The next steps are: studying the vendor’s support portal, making direct inquiries to hardware and software manufacturers about their Y2K38 status, and, as a last resort, verification through testing.
When testing corporate systems, it’s critical to take special precautions:
If a system is found to be vulnerable to Y2K38, a fixing timeline should be requested from the vendor. If a fix is impossible, plan a migration; fortunately, the time we have left still allows for updating even fairly complex and expensive systems.
The most important thing in tackling Y2K38 is not to think of it as a distant future problem whose solution can easily wait another five to eight years. It’s highly likely that we already have insufficient time to completely eradicate the defect. However, within an organization and its technology fleet, careful planning and a systematic approach to solving the problem will allow to actually make it in time.
Security leaders chart course beyond predictions with focus on supply chain, governance, and team efficiency.
The post Forget Predictions: True 2026 Cybersecurity Priorities From Leaders appeared first on SecurityWeek.
Ransomware remains the biggest concern for CISOs in 2026, according to WEF’s Global Cybersecurity Outlook 2026 report.
The post Cyber Fraud Overtakes Ransomware as Top CEO Concern: WEF appeared first on SecurityWeek.
Here we examine the CISO Outlook for 2026, with the purpose of evaluating what is happening now and preparing leaders for what lies ahead in 2026 and beyond.
The post Cyber Insights 2026: What CISOs Can Expect in 2026 and Beyond appeared first on SecurityWeek.
I recently participated in a security leader roundtable hosted by Cybersecurity Tribe. During this session, I got to hear firsthand from security leaders at major organizations including BNP Paribas, the NFL, ION Group, and half a dozen other global enterprises.
Across industries and maturity levels, their priorities were remarkably consistent. When it comes to AI-powered SOC platforms, these are the seven capabilities every CISO is asking for.
If there was one theme that came up more than anything else, it was trust. Security leaders don’t want “mysterious” AI. They want transparency.
They repeatedly insisted that AI outputs must be auditable, explainable, and reproducible.
They need to show the work, for compliance auditors, for internal governance boards, and increasingly to address emerging legal and regulatory risk.
Black-box decisions won’t cut it. AI must generate evidence, not just conclusions.
Every leader I spoke with is wrestling with alert overload. Even mature SOCs are drowning in low-value notifications and pseudo-incidents.
A measurable reduction in alerts escalated to humans is now a top KPI for evaluating AI platforms. Leaders want an environment where analysts spend their time on exploitable, high-impact threats, not noise.
If AI can remove repetitive triage work, that’s not just helpful, it’s transformational.
No one wants yet another dashboard that nags them about high CVSS scores on systems nobody actually cares about.
CISOs want AI that can fuse:
The goal is prioritization that reflects real organizational risk, not arbitrary severity scores.
They want AI to tell them: “This is the one alert that actually matters today and here’s why.”
Get your editable copy of the one deck you need to pitch your board for 2026 AI SOC budget.
Most leaders are open to selective autonomous remediation, but only in narrow, well-defined, high-confidence scenarios.
For example:
But for broader or higher-impact actions, CISOs still want human review. The tone was clear:
AI should move fast where appropriate, but never at the expense of control.
Every leader emphasized that an AI platform is only as good as the data it can consume.
The must-have list included:
They don’t want a magical AI that promises answers without good data.
They want a connected system that can see across the entire environment.
CISOs aren’t implementing AI in a vacuum. Their boards and executive leadership teams are pressuring them from two very different angles:
To navigate this dynamic, CISOs need clear, defensible ROI:
AI without measurable value is no longer acceptable.
They need something they can put in front of the board and say, “Here’s the impact.”
Before enterprises allow AI to autonomously take security actions, CISOs need a fundamental question answered:
“Who is accountable when the AI acts?”
This isn’t just a theoretical concern. It’s a gating requirement for adoption.
Until there is clear guidance on liability, responsibility, and governance, many organizations will keep AI on a tight leash.
Across all of these conversations, the message was consistent:
AI in the SOC is inevitable, but it must be safe, transparent, integrated, and measurable.
CISOs aren’t looking for science fiction. They’re looking for credible, operational AI that enhances their teams, strengthens their defenses, and aligns with business realities.
Read about why the best LLMs are not enough for the AI SOC.
The post The 7 CISO requirements for AI SOC in 2026 appeared first on Intezer.
Login