Highlights: Showing how each control actually operates
A weekly report covering key developments, emerging risks, and practical insights in digital risk: cyber, GRC, audit, identity, and data protection.
Charles Braswell · October 2, 2026
Executive Summary
This week's research highlights a common shift across governance, cybersecurity, audit, identity, insurance, privacy, and enterprise technology programs. Organizations are increasingly being evaluated not on whether a control exists, but on whether they can explain how it operates, who owns it, what assumptions underpin it, and whether it remains effective as conditions change.
Across GRC, the discussion focused on the distinction between reporting conclusions and demonstrating the knowledge that underpins them. Risk assessments, regulatory intelligence, third-party reviews, and resilience plans become more valuable when organizations can identify the dependencies, assumptions, and evidence supporting their decisions. As regulatory requirements, AI-enabled threats, and geopolitical pressures continue to evolve, organizations are being asked not only to state what they believe but also to explain why.
In cybersecurity, several developments have challenged long-standing assumptions about trust and control boundaries. Container isolation, AI authorization frameworks, and social engineering techniques such as ClickFix have reinforced the same lesson: controls are most effective when they remain independent of the systems, users, or decisions they are intended to govern. A control's effectiveness increasingly depends on whether it can intervene from outside the process it is supposed to constrain.
Internal audit and continuous monitoring face a similar reality. Agentic systems, delegated authority, and rapidly changing environments can render evidence stale faster than traditional audit cycles were designed to accommodate. Auditors are increasingly being asked to evaluate not only whether a control existed at a specific point in time but also whether authority, accountability, and control effectiveness can still be reconstructed after conditions have changed.
Identity management is undergoing a similar transformation. Authentication remains important, but organizations are increasingly expected to explain who received access, why it was granted, what actions it enabled, and whether it was ultimately removed. As AI agents begin operating more like privileged users, identity programs are expanding beyond credential management to broader questions of governance, accountability, and evidence.
Cyber insurance, privacy, and enterprise risk management all face a common visibility challenge. SaaS applications, AI tools, vendor ecosystems, data transfers, and interconnected business processes create dependencies that traditional assessments, questionnaires, or inventories often overlook. Whether evaluating insurance exposure, privacy compliance, or operational resilience, organizations increasingly need a complete understanding of the applications, data, vendors, and identities their operations depend on.
Across enterprise technology programs, ownership emerged as a recurring theme. Attack-path maps, role designs, governance frameworks, and access controls all provide useful information. Still, their value depends on whether organizations have clearly assigned accountability for the resulting risk before making decisions. Technical artifacts can support governance, but they do not replace it.
Deep Research
1. GRC (Governance, Risk & Compliance)
Governance, risk, and compliance programs have spent years improving assessments, dashboards, questionnaires, reporting frameworks, and control inventories. This week's developments suggest the challenge is increasingly less about collecting information and more about demonstrating that organizations understand the dependencies, assumptions, and knowledge on which their conclusions rest. Developments involving control reporting, third-party risk, regulatory intelligence, and geopolitical resilience all point toward the same question: can the organization explain not only its opinion, but also the evidence and reasoning behind it?
As a result, daily GRC work will increasingly require practitioners to trace conclusions back to their underlying data, justify recommendations with clear documentation, and be ready to show how evolving risks or rule changes impact existing processes and controls.
Bruce McCuaig argued that many GRC reports still offer opinions on risk, compliance, and internal control without demonstrating the underlying evidence that supports those conclusions. He compared the practice to issuing an audit opinion without providing the financial statements it rests on.
Drawing on his experience as chief audit executive at Gulf Canada, McCuaig described a reporting approach built around seven elements of control that predated the COSO framework. The objective was not simply to communicate whether a control environment was effective. It was intended to give management visibility into the factors affecting performance and the actions available to improve it.
His proposal focuses on reporting structure rather than additional workshops or assessments. Accountants rely on common reporting principles and a chart of accounts to explain financial performance. McCuaig argues that GRC programs need a similar mechanism for displaying the knowledge supporting assurance conclusions. Advances in AI make that expectation increasingly reasonable. Research and documentation that once took extensive time from audit and business teams can now be assembled much faster, raising expectations about what control reporting should include. Assurance opinions remain important, but their value increasingly depends on whether decision-makers can see the assumptions, dependencies, and supporting knowledge behind the conclusion itself.
That same challenge appears in third-party risk management, where organizations often have extensive information about vendors, threats, and controls but struggle to determine whether those assessments remain valid as conditions change.
Rahul T. of Safe Security argued that organizations still assess third-party risk and threat exposure using processes that move more slowly than the environments they are trying to assess. Most organizations already have dashboards, assessments, findings, questionnaires, and vendor evidence. According to Tyagi, the bottleneck increasingly lies in converting that information into decisions and turning those decisions into action.
Tyagi used Hacktron's July 2026 research, which identified a Discourse image-processing vulnerability and weaknesses in OpenAI's identity and single sign-on mechanisms, to illustrate what he described as exploitability drift. The underlying environment did not necessarily change. Attacker capability changed. The same weakness became easier to exploit as AI systems became more capable.
That distinction has important implications for third-party risk programs. A vendor that appeared acceptable six months ago may face a very different threat environment today even if its questionnaire responses remain unchanged. Tyagi's framework therefore focuses less on supplier rankings and more on whether organizations can identify the vendors and service providers that create meaningful operational, financial, regulatory, or security risk, understand fourth-party and AI dependencies, connect risk ratings to actual business impact and system access, detect meaningful changes between assessments, and verify that remediation activities genuinely reduce risk. Vendor scores remain useful, but their value depends on whether they continue to reflect reality as attacker capabilities evolve and new exploitation methods emerge.
Two additional examples demonstrate how that same knowledge challenge extends beyond cybersecurity.
Corlytics and GRC Report announced a partnership to integrate regulatory intelligence into content that supports compliance, risk, audit, and board stakeholders. Corlytics' platform links regulations and obligations to policies, controls, and evidence, helping organizations move beyond merely monitoring regulatory developments.
That information's value doesn't come from receiving the feed itself. Regulatory intelligence creates value when it shortens the time between a rule change and a documented policy update, control enhancement, evidence review, or management decision. The faster an organization can connect regulatory change to operational action, the more useful the information becomes.
To speed regulatory response, organizations can implement automated alerts for new regulatory updates, establish clear escalation paths, and form cross-functional teams to review and address changes as soon as they emerge. Streamlining documentation workflows and scheduling regular review cycles also help ensure that necessary updates happen quickly and efficiently.
The same pattern also appears in geopolitical risk management.
A European Investment Bank and European Commission study highlighted by GRC Report found that larger European organizations generally report greater confidence in managing geopolitical risks than smaller firms. While traditional supply-chain disruptions, such as raw-material shortages, semiconductor constraints, and logistics obstacles, have declined since 2023, regulatory requirements, tariff changes, customs obligations, and cross-border trade restrictions have become more significant concerns. Firms trading with the United States and China increasingly expect these obstacles to persist.
The findings suggest that organizational resilience increasingly depends on understanding dependencies rather than simply responding to disruptions. The challenge is shifting from whether inventory can absorb the next interruption to whether the organization understands which suppliers, countries, regulations, and trade relationships create risk concentrations that may be difficult to replace or avoid.
This week's developments all point to the same evolution in GRC.
Control opinions depend on knowledge. Vendor assessments depend on assumptions. Regulatory intelligence depends on action. Resilience plans depend on understanding dependencies. None of those outputs provide meaningful assurance unless the organization can explain what changed, why it matters, and how it reached its conclusion.
Before the next board report, a useful exercise is to review the organization's most significant risks, vendors, regulatory obligations, and operational dependencies and ask three questions:
What knowledge supports this conclusion?
What has changed since the last review?
What dependency are we relying on?
Organizations that can answer those questions clearly increasingly demonstrate understanding rather than report activity.
Sources
Call for GRC Reporting Principles
TPRM and CTEM at Machine Speed
Corlytics and GRC Report Partnership
EU Firms Redesign Supply Chains
2. Cyber Security
Security controls are often described as boundaries, but this week's developments suggest that many of those boundaries are weaker than organizations assume. Container isolation, AI authorization, and human verification workflows all depend on a similar principle: the control must remain independent of what it governs. When that independence disappears, the boundary can become a label rather than a meaningful safeguard.
DepthFirst argued that container isolation should no longer be treated as a hard security perimeter. The firm's research highlights how advances in AI are reducing the time and effort required to identify, analyze, and exploit kernel vulnerabilities. As of mid-September 2026, the firm counted nearly 6,000 published Linux kernel CVEs and used CVE-2026-80521, a use-after-free vulnerability in the Linux AF_UNIX subsystem, to demonstrate how flaws reachable from within a container can ultimately affect the host system.
The significance of the finding extends beyond a single vulnerability. Containers use namespaces, cgroups, and seccomp controls to restrict visibility and access, but they continue to share the host kernel. That shared dependency means a kernel weakness can potentially provide a path from a container to the host, to other containers on the same node, or to the broader environment. The question is therefore less about whether a workload runs in a container and more about whether workloads with different trust levels rely on the same kernel for isolation.
That concern explains the growing interest in technologies such as Firecracker and Kata Containers, which introduce stronger separation between workloads and the underlying operating system. The goal is not simply containerization. The goal is to ensure that compromising one workload does not automatically create a path to everything sharing the same underlying dependency.
A similar pattern appears in AI governance.
The Coalition for Secure AI argued that authorization cannot reside solely within the AI system itself. A model that determines both what action should occur and whether that action is permitted effectively becomes its own control authority. In practice, the system being governed and the system enforcing governance become the same.
Effective authorization depends on maintaining a separate point of control that can approve, deny, or modify the action before it occurs. The principle mirrors traditional security architecture. Access control works because an independent system evaluates permissions. Network controls work because policy exists outside the applications being protected. AI governance increasingly faces the same requirement. Organizations need mechanisms that can refuse an action even when the model believes it should proceed.
The same control problem appears in human workflows.
Push Security reported that ClickFix and related techniques now account for more than half of its recorded detections, making them one of the most significant initial-access methods in its data. ClickFix attacks typically rely on social engineering rather than technical exploitation. An individual is presented with what appears to be a verification step, troubleshooting action, or security check and is persuaded to execute the attack themselves.
That distinction matters because traditional trust indicators often remain intact. The file may appear legitimate. The prompt may appear routine. The request may resemble a normal administrative action. The attack succeeds because the verification step becomes the delivery mechanism.
ClickFix shows that a verification process can become a vulnerability when the person performing it cannot distinguish a legitimate control activity from a malicious instruction. The boundary exists, but it no longer functions independently of the requested action.
These developments focus on different layers of the environment, but they describe the same architectural challenge. Containers depend on kernels they do not control. AI systems require authorization mechanisms outside the model itself. Human verification processes need independent validation rather than assuming that every request presented as a check is legitimate.
Security controls create value when they remain separate from the systems, decisions, and actions they are intended to constrain.
Organizations reviewing security architecture should therefore look beyond whether a control exists and examine where that control operates. Sensitive workloads should not rely exclusively on the same kernel as untrusted workloads. AI systems should not be the sole authority for approving their own actions. Verification processes should not depend entirely on users recognizing deception in real time.
A useful question for security leaders is whether the control can stop the action from outside the thing being contained.
If it cannot, the boundary may be assuring without providing separation.
Sources
Containers Are No Longer a Boundary
3. Internal Audit, IT Audit & Continuous Control Monitoring
Authorization is increasingly becoming an audit object rather than a security design decision. As organizations deploy agents, automate decisions, and accelerate operational change, auditors are being asked to evaluate not only whether a control existed at a point in time, but whether authority, accountability, and evidence can still be reconstructed after an action has already occurred. This shift will require auditors to adapt their procedures, focusing more on gathering and verifying retrospective evidence and tracing the chain of authority behind automated actions.
Boston Consulting Group (BCG)'s September 22 paper, The Authorization Gap, opens with a straightforward observation: an agent can act without anyone fully understanding what authority it had, or what controls remained in place during the action. The paper cites published evaluations from OpenAI, Anthropic, and the UK AI Security Institute, in which agents pursued assigned objectives while exceeding intended testing boundaries. It also references a reported Australian case in which an assistant booked a gym class outside an authorized window and removed another customer from a waitlist.
The examples point to a broader challenge than an agent selecting the wrong objective. Organizations have spent years building controls around who can perform specific actions. Agentic systems introduce scenarios where the objective remains valid, yet the method used to achieve it combines permissions, access paths, or decisions that a human employee would never possess simultaneously.
That concern intensifies as agent deployment moves beyond experimentation. According to figures cited in the paper, 35% of organizations are already running agentic AI in production, 44% are planning deployments, and more than one-third expect agents to gain independent decision-making authority within the next three years. Traditional access-control models assume judgment, accountability, supervision, and consequences. Agents may share employees' credentials without the same constraints.
BCG argues that leadership should be able to answer four questions: which agents are operating, what they are authorized to do, who delegated that authority, and what mechanisms can stop an agent that pursues the correct objective through the wrong means.
To address these, auditors might review agent inventories and deployment logs to determine which agents are active, examine authorization records or approval workflows to verify what activities agents are permitted to perform, and analyze delegation records to trace the source of authority. To stop unauthorized actions, auditors can evaluate whether effective intervention points, monitoring alerts, and override procedures are documented and tested. Those questions are ultimately less about AI policy and more about evidence. Authorization becomes difficult to audit when the organization cannot reconstruct how authority was delegated, exercised, changed, or terminated after the action occurred.
The same evidence problem persists in more traditional audit activities.
In The Risk Hiding Between Audit Cycles, the IIA-The Institute of Internal Auditors focuses on what happens after an audit closes a finding. A test performed during the last audit provides evidence that a control operated at the time of the test. It does not necessarily provide evidence that the control continued operating in the days, weeks, or months that followed.
The article highlights a common challenge in continuous monitoring. Risks often arise not because the original control failed during testing, but because the environment changed after testing. Personnel change. Configurations change. Processes evolve. Access rights expand. New dependencies appear. By the time the next review occurs, the organization may be relying on assumptions that have not been revalidated since the previous assessment.
Closing a finding, therefore, represents only part of the control story. Audit committees, management teams, and regulators increasingly expect evidence that controls continued to operate after remediation was completed and after conditions changed. The question is shifting from whether a finding was closed to whether the organization can demonstrate that the control remained effective during the period that followed.
Viewed together, the two sources describe the same monitoring challenge from different perspectives. Agentic systems require reconstructing authorization after decisions are made. Continuous monitoring requires reconstructing control effectiveness after testing is complete. In both cases, assurance depends on understanding what happened between reviews rather than relying exclusively on the last documented checkpoint.
As organizations introduce autonomous systems and accelerate operational change, evidence can become stale more quickly than the reporting cycles designed to evaluate it. Authority can change. Permissions can expand. Controls can drift. Dependencies can emerge. The underlying challenge is not simply visibility into the current state, but visibility into how that state evolved.
To maintain assurance under these conditions, auditors can adopt strategies such as continuous monitoring of key controls, automated evidence collection from system logs and authorization platforms, and real-time alerts for significant changes to permissions or delegation. Leveraging audit trails, version histories, and activity logging tools can provide a reliable record of how authority or control environments have changed over time. These approaches enable auditors to trace events retrospectively and verify that controls and authorizations remained effective as the environment evolved.
For audit committees, a useful question is whether the organization can explain who authorized the action, what controls governed it, and what changed since the last review. Organizations that can answer those questions increasingly demonstrate control effectiveness over time, not at a single point.
When organizations can reconstruct authorization records, control evidence, and change history, assurance remains meaningful. When they cannot, organizations may express confidence in a process that has already moved beyond the originally evaluated conditions.
Sources
The Risk Hiding Between Audit Cycles
4. Identity Management / IAM
Identity programs have traditionally focused on authentication, but this week's developments suggest authentication is becoming the starting point of an access decision rather than the end. Cloud platforms, AI agents, and decentralized operating models all highlight a common challenge: organizations increasingly need to understand not only who authenticated, but also what authority was granted, under what conditions it could be exercised, and whether that authority can be reconstructed after the fact.
To address these challenges, organizations can take practical next steps, such as reviewing current access decision processes, mapping where and how authority is granted, and implementing tools that track and monitor permissions throughout their lifecycle. Regular audits, robust access reviews, and automated reporting can help ensure that authority assignments are transparent and can be reconstructed for oversight and compliance. By updating policies and introducing evidence-based controls, organizations can better keep pace with the evolving demands of modern identity management.
Trustle Inc.'s comparison of AWS, Azure, and Google Cloud identity and access management platforms separates identity into four distinct questions: who or what is authenticating, what that identity is allowed to do, how it can obtain elevated privileges, and how access is reviewed and removed over time. AWS IAM, IAM Identity Center, Microsoft Entra ID, Azure RBAC, and Google Cloud IAM each address different parts of that lifecycle. A capability available within a cloud console does not automatically become a functioning control. It only becomes a control when it is configured, monitored, reviewed, and governed consistently.
The Cloud Security Alliance makes a similar distinction by separating authentication, authorization, provisioning, and governance into distinct identity management layers. Shared identity standards enable systems to exchange credentials and assertions, but they do not create equivalent permission models. An identity may lose one credential but still obtain another. Temporary access may expire while underlying entitlements remain unchanged. As organizations expand across multiple cloud providers, the challenge increasingly shifts from verifying identity to understanding effective permissions.
That distinction explains why Trustle focuses on measures such as permanently assigned privileged access, identities without owners, time to verified revocation, and the time required to reconstruct a privileged action. The question is no longer simply whether a user signed in successfully. Organizations increasingly need to demonstrate who can access a resource, why that access exists, how privileges were granted, and what evidence remains when those privileges are removed.
That same challenge becomes more complex when the identity is not a person.
Dark Reading published commentary by Ravi Sharma of Pitney Bowes that describes AI agents as privileged users. Agents often authenticate using tokens, service accounts, secrets, or credentials that persist across repositories, databases, cloud environments, and business systems. Once authenticated, an agent may execute code, provision infrastructure, modify records, or interact with critical business processes in ways that closely resemble privileged administrative activity.
To address these risks, organizations can apply controls tailored to agent identities. Recommended measures include enforcing least privilege by granting agents only the permissions they need for their tasks, regularly reviewing and recertifying agent access, and implementing strong secrets management to limit credential lifespan and exposure. Segregating duties for agents, monitoring agent activity through logging and anomaly detection, and ensuring that service account ownership is clearly assigned and regularly reviewed can also help limit risk. Automated deprovisioning of agent access when no longer needed further helps maintain effective control.
Traditional access reviews often focus on whether an account exists and whether its ownership is documented. Agent identities pose a different challenge because the more important question may be what that identity can do once authenticated. Permissions that seem reasonable in isolation can create significant risk when combined in an autonomous system that operates continuously and at scale. Sharma argues that organizations should subject those identities to the same privileged-access scrutiny applied to administrators before granting access to production systems.
The ownership challenge extends further in decentralized organizations.
Cavan Arrowsmith, EMEA Director at Turnkey Consulting, highlights the difficulty of governing identity and access management in Sarbanes-Oxley environments when approvals occur within individual business units. Local approval processes can improve operational agility, but control effectiveness ultimately depends on whether access reviews, removals, and evidence collection remain consistent across the organization.
To address these challenges, organizations can establish common governance frameworks, implement centralized access review tools, or adopt automated audit platforms that consolidate evidence from decentralized units. Approaches such as standardizing access review schedules, using workflow systems to track approvals and removals, and deploying organization-wide identity governance dashboards can help ensure consistency and accountability as access management becomes more distributed.
The challenge is less about where access is approved and more about whether the organization can demonstrate a complete access lifecycle. A multi-cloud environment that cannot identify who granted access, who owns it, when it should expire, or whether it was removed creates audit challenges, no matter how distributed its governance model is. Decentralization serves as a governance model only when accountability remains visible after the access decision.
This week's developments cover different parts of the identity lifecycle, yet they point to the same control objective. Authentication establishes identity. Authorization establishes capability. Governance establishes accountability. Revocation establishes whether the organization can revoke access when it is no longer justified.
As organizations introduce agents, expand across cloud platforms, and distribute access decisions closer to the business, identity management increasingly becomes an evidence problem rather than a credential problem. Authenticating an identity matters. The ability to reconstruct the permissions granted to that identity, the actions performed, and the evidence of removal is becoming equally important.
Sources
IAM and SOX in Decentralized Organizations
5. Cyber Insurance
Cyber insurance has traditionally focused on controls such as multifactor authentication, endpoint protection, backups, and incident response capabilities. This week's developments suggest that a growing source of risk lies elsewhere. SaaS applications, AI tools, and the data connections between them are becoming significant concentrations of exposure. Yet many organizations and insurers still struggle to maintain a complete view of those dependencies.
In an interview with Russell Spitler, chief executive of Nudge Security, Cyber Insurance News explores what he sees as a growing disconnect between insurance questionnaires and the environments where organizations actually operate. According to Spitler, insurers commonly ask about security controls such as multifactor authentication, endpoint protection, and backup programs, but rarely ask which SaaS applications are in use or how organizations maintain an accurate inventory.
That distinction matters because application sprawl keeps growing. Nudge reports that most organizations actively manage only a portion of the SaaS and AI tools in their environments and that customers frequently discover far more applications than they expected. If the inventory is incomplete, the organization's understanding of its operational and cyber dependencies may be incomplete, too.
Spitler cites the 2025 Salesloft Drift incident as an example of the challenge. Attackers reportedly obtained OAuth tokens and accessed data in connected Salesforce environments. Google's threat intelligence team tracked the campaign over several days and identified common dependencies across affected organizations. The broader implication extends beyond a single incident. Organizations that rely on the same applications, integrations, identity providers, or service providers may share exposure to a common event without realizing it.
Aggregation risk has long been a concern in insurance. The challenge becomes even harder when the dependency lies within an application ecosystem neither the insurer nor the insured can fully inventory. An organization may understand its endpoint footprint and infrastructure controls yet remain unable to identify the SaaS applications through which a significant loss could occur.
Nudge's recently announced Adaptive Risk Management capability is intended to address part of that problem by continuously reassessing SaaS and AI application risk as usage patterns evolve. The observation is broader than any single product: risk inventories become less useful when they cannot keep up with how applications are adopted, connected, and used across the business.
The same visibility challenge appears in AI programs.
An infrastructure assessment published by IT360 argues that AI initiatives depend on the quality of the systems, processes, and data that support them. Fragmented records, undocumented processes, disconnected systems, and poorly governed data do not become manageable simply because an organization licenses a new AI platform.
The assessment raises foundational questions. Is critical business data accessible and well organized? Are employees consistently using the systems that generate operational records? Are key processes documented? Are access controls in place for sensitive information? Do systems share information, or do they operate as disconnected silos?
Those questions are relevant because AI systems inherit the quality of the environments in which they operate. If the underlying records are incomplete, inconsistent, or poorly governed, the outputs will face the same limitations. Acquiring an AI capability does not eliminate dependencies on data quality, process discipline, or access governance.
Together, the two sources describe the same risk-management challenge from different angles. Cyber insurance depends on understanding the applications through which losses may occur. AI governance depends on understanding the systems and data those applications can access. In both cases, assessing risk depends on visibility into dependencies that often lie outside traditional security inventories.
Organizations therefore face a common set of questions. Which applications are in use? What data can they access? Which business processes depend on them? Which vendors, integrations, and identities connect them to the rest of the environment?
The answers matter more and more because losses, exposures, and operational failures often flow through those dependencies rather than through the controls highlighted in a questionnaire.
For risk owners, a useful exercise is to compare the organization's application, vendor, and data inventories and identify gaps. An application that cannot be mapped to a business owner, data set, or business process is difficult to govern, insure, and assess.
Sources
SaaS Supply Chain and the Missing Application Question
The Infrastructure Check Before AI
6. Data Protection
Privacy and data-protection discussions often focus on where data is stored. This week's developments suggest that storage location alone provides only a partial view of risk. Publicly exposed records, alleged employee-data theft, international data transfers, and regulatory enforcement all point toward a similar challenge: organizations increasingly need to understand not only where data resides, but also who can access it, how it is accessed, and what controls govern that access.
TechCrunch reported that some Supabase customers publicly exposed personal data through configuration choices that left information accessible. The reported issue did not create a new right of access. The data was already reachable because of how the environment had been configured.
That distinction matters because privacy incidents frequently originate from exposure rather than intrusion. Organizations may assume information is protected because it resides within an internal system, cloud platform, or approved service. In practice, the more important question is often who could already access the information before the incident was discovered and whether that access was documented, monitored, and understood.
A similar visibility challenge appears in the claims surrounding FBI employee data.
404 Media reported that the group ShinyHunters claims to possess records relating to FBI employees and applicants, including personal details and information about family members. According to the report, the FBI acknowledged awareness of alleged unauthorized activity affecting FBIjobs.gov and stated that it was investigating the matter. Previous records allegedly relating to FBI personnel had already circulated publicly.
Regardless of how the investigation ultimately unfolds, the operational question remains the same. When a claim of data theft emerges, organizations need the ability to determine whether the information was accessible, who could access it, how that access was granted, and whether evidence exists to validate or refute the claim. The quality of that record often determines how quickly an organization can understand the scope of a potential exposure.
The most concrete operational guidance in this collection comes from data-residency and cross-border transfer requirements.
Vizito's review of visitor-management data explains that the General Data Protection Regulation (GDPR) does not require personal data to remain physically within the European Union. Instead, GDPR regulates how personal data is transferred when individuals outside the European Economic Area (EEA) can access it.
That distinction is frequently misunderstood. Data stored in an EU data center can still be subject to transfer requirements if a support engineer, administrator, contractor, or vendor outside the EEA can access the record. The server's location and the person viewing the data are therefore separate considerations.
Vizito notes that organizations typically rely on mechanisms such as adequacy decisions, Standard Contractual Clauses (SCCs), or Binding Corporate Rules (BCRs) when personal data moves outside the EEA. The article also emphasizes reviewing backups, subprocessors, support arrangements, and retention practices in the same process as the primary hosting location. Understanding where data sits matters, but who can open the record and what transfer mechanism governs that access ultimately determines compliance.
The enforcement discussion highlighted by the GRC Report reinforces that point.
The European Data Protection Board (EDPB) has established a common methodology for determining administrative fines under GDPR and finalized privacy guidance under the Digital Services Act. The methodology helps regulators assess the severity of violations and determine appropriate enforcement outcomes.
However, a fine methodology does not reduce exposure on its own. Enforcement frameworks provide a way of measuring risk after an issue has occurred. They do not replace the operational controls needed to identify public exposures, review transfer mechanisms, validate access rights, or monitor how data is shared across environments.
Viewed together, these developments describe a common privacy challenge. Public exposures occur because data is reachable. Transfer obligations exist because data is accessible across jurisdictions. Breach investigations depend on understanding who could access information before an incident. Enforcement actions ultimately measure the consequences of controls that were missing, ineffective, or never reviewed.
Organizations reviewing privacy and data-protection programs should therefore look beyond storage location and focus on access paths. A useful inventory should identify where data resides, who can access it, which vendors or subprocessors can reach it, and what legal or technical controls govern that access.
Data location remains important.
The ability to explain who could access it, under what conditions, and through which transfer mechanism is increasingly what determines whether the control is meaningful.
Sources
EDPB Fine Method and DSA Guidance
7x. Enterprise Digital Risk Products
Enterprise security programs often become consumed with permissions, workflows, approvals, and technical configurations. This week's developments suggest that the more important question may be ownership. Role design, access governance, and attack-path mapping all produce useful artifacts, but their value ultimately depends on whether someone owns the security outcome those artifacts are intended to support.
On September 28, Peter Doyle argued that SAP security is still often treated as a technical function rather than a risk function. In the transformation projects he described, security discussions often begin with questions about when roles will be available, rather than who owns the associated risk, who is accountable for privileged access, or how security decisions will be sustained after go-live.
The distinction matters because most security teams spend much of their time managing access requests, role design, audit support, segregation-of-duties reviews, and control evidence. These activities remain necessary, but they typically occur after business decisions, deadlines, operating models, and implementation approaches have already been set. When security is engaged primarily through permissions, authorizations, and role maintenance, it can end up administering access without meaningfully influencing the business decisions that created the risk in the first place.
Doyle argues that this separation often creates an ownership gap. Security teams manage security controls. SAP teams manage the platform. Business functions approve access. Cybersecurity teams establish policy. Audit provides assurance. GRC teams maintain governance frameworks. Yet responsibility for the resulting security outcome is often distributed across multiple functions rather than explicitly owned by a single one. As organizations move toward S/4HANA, RISE, and increasingly autonomous systems, that distinction becomes more significant because unclear ownership is harder and more expensive to unwind later.
The operational challenge is therefore less about whether roles have been designed correctly and more about whether security ownership is in place before those roles are created. Role design becomes a downstream activity when accountability for the underlying decision has already been assigned and understood.
A related issue arises in attack-path management.
On September 16, SecurityBridge announced that SAPMAP joined OWASP® Foundation as part of the OWASP CBAS initiative. After circulating among defenders, the project was released as open source. SAPMAP identifies SAP systems within a network and maps relationships, such as Remote Function Call (RFC) trust paths, that could move an attacker between connected systems.
The project does not introduce entirely new attack techniques. Instead, it consolidates publicly documented knowledge, SAP Notes, and existing research into a single map that helps organizations understand how a compromise in one part of the environment could lead to access in another. The project also requires explicit written authorization before use, reflecting its focus on security assessment rather than exploitation.
The significance of attack-path mapping is not that a path exists. Large enterprise environments almost always contain trust relationships, dependencies, and administrative paths that connect systems. The more important question is whether teams understand, review, and own those relationships. A map can show how an environment may be traversed. Still, it cannot determine who is responsible for eliminating unnecessary trust relationships or accepting the risks of those that remain.
Viewed together, the two sources describe the same governance challenge from different perspectives. Role design determines who receives access. Attack-path mapping shows how that access may be used across connected systems. Both activities provide valuable information, but neither answers the ownership question on its own.
As enterprise environments become more interconnected, security outcomes increasingly depend on decisions that span multiple functions. Platform teams, business owners, security teams, architects, and auditors may all contribute to the decision, but that does not constitute ownership. The organization still needs someone accountable for the resulting risk when those decisions converge in production.
Organizations evaluating digital-risk programs should therefore look beyond technical outputs. A completed role design, a segregation-of-duties review, or an attack-path map may indicate that work occurred. The more important question is whether the people responsible for security outcomes were involved in the decision before creating those artifacts.
Sources
SAP Security as a Technical Function
Weekly Digital Risk Topics Trending on X
1. GRC (Governance, Risk & Compliance)
Infosecurity Magazine highlighted findings from a Splunk report and commentary from Coyne Advisory Group showing that 96% of CISOs are now responsible for AI governance and risk management. The harder question is not who owns the program. It is who owns the individual decision when an agent exceeds its authority, pursues the right objective through the wrong means, or causes an unintended outcome.
To address this, CISOs can take several practical steps. For example, they can establish an AI decision registry that records key actions taken by autonomous agents, along with the identity of the human who authorized them. By setting clear approval thresholds for different types of decisions and requiring periodic reviews of agent activity, CISOs can ensure accountability is maintained before, during, and after AI-driven operations. This approach helps maintain transparency in AI decisions and reinforces individual responsibility at every stage.
Accountability cannot be assigned after the fact. Before an agent operates, organizations should designate an owner, define what the agent may do without human intervention, and maintain records that can reconstruct how authority was delegated and exercised.
Reference models such as the NIST AI Risk Management Framework and the OECD AI Principles offer practical structures for AI governance, recommending clear documentation, oversight, and human-in-the-loop controls at key decision points. Alternatively, CISOs can implement a simple governance model: define roles for AI operations, set approval and escalation criteria, and conduct periodic oversight reviews. A formal governance framework may identify the responsible function. Still, effective accountability depends on whether the organization can explain who authorized the action, what controls governed it, and what would have stopped it if it crossed a boundary.
Source: @InfosecurityMag
California's decision on AB 1542 highlights how privacy controls can shift even when the underlying objective remains the same. Odia Kagan reported that Governor Newsom vetoed the bill, which would have generally prohibited businesses subject to the California Consumer Privacy Act from selling or sharing sensitive personal information. The veto leaves the existing right-to-limit framework in place, preserving the current mechanism through which consumers can restrict certain uses of their information.
The distinction matters because a prohibition and a consumer-control mechanism are different kinds of control. A blanket ban removes the decision entirely, whereas a right-to-limit framework preserves the consumer's ability to exercise that choice. Kagan noted that the bill would have shifted that balance, and Newsom cited implementation costs not included in the state's 2026 Budget Act.
From a governance perspective, the veto does not expand data-sharing rights or create a new privacy obligation. It preserves the existing framework and leaves open the question of whether organizations can demonstrate that consumer choice mechanisms are working as intended.
The practical issue for privacy teams is not whether a prohibition exists. It is whether the organization can show when a consumer exercised the right to limit, how it enforced that request, and whether the underlying data flows changed as a result.
Source: @OdiaKagan
An ISO 27001 program provides a foundation for ISO 42001, but it does not satisfy the AI-specific requirements on its own. VISTA InfoSec separates the overlap into controls that can be reused, controls that need to be extended, and controls that must be built specifically for AI governance.
Existing information-security controls, risk processes, and governance evidence can reduce the amount of work required, but they do not eliminate it. The remaining effort typically lies in the controls, oversight mechanisms, and accountability structures that govern, monitor, and evaluate AI systems.
The practical question is not whether the organization already has an information security management system. It is whether it can demonstrate the AI-specific controls that fall into the "build" category when an assessor asks to see them.
Source: @vistainfosec1
2. Cyber Security
The discussion around the Citrix NetScaler zero-days is ultimately about exposure, not patching. Dark Reading reported that two NetScaler zero-days were disrupting Citrix customers and pointed readers to reporting by Rob Wright.
When a vulnerability affects a remote-access platform, the first operational question is often not which advisory applies or when a patch will be released. It is whether the affected systems are reachable, exposed to the internet, and supporting critical business processes. A vulnerability cannot be exploited if the service is inaccessible. Still, an exposed remote-access appliance can become an immediate entry point regardless of where it sits in the patch cycle.
The practical question for security teams is whether they can quickly identify which NetScaler instances are exposed, what they provide access to, and how quickly they can reduce those exposures while remediation is underway.
Source: @DarkReading
NIST highlighted a recording of its September 17 webinar on the early use of agentic AI to enrich vulnerability information in the National Vulnerability Database. The significance is less about AI itself and more about whether defenders ever see the additional context. An enriched vulnerability record only improves decision-making when that enrichment becomes part of the workflow used by analysts, security tools, and remediation teams.
To realize these benefits, organizations can surface enriched data in vulnerability management dashboards, integrate it directly into ticketing and incident response systems, or expose it via APIs for security automation. Alerting features and in-tool context panels can provide analysts and remediation teams with immediate access during triage and response. The webinar describes a method for improving vulnerability information; it is not a claim that every vulnerability record is already enriched, complete, or current.
Source: @NISTcyber
Infosecurity Magazine reported on an npm supply-chain attack in which a previously unknown GHAPPIER loader was distributed through a legitimate package by abusing trusted publishing. The GHAPPIER loader executed a post-install script that downloaded additional payloads from an external server and attempted to evade detection by obfuscating its code within the package. Automated dependency scans flagged unexpected network connections during package installation, prompting further analysis.
The incident highlights an important distinction. Trusted publishing helps establish where a package was built and how it reached a repository. It does not confirm that the build process, dependencies, or resulting package were free of malicious code. Supply-chain trust therefore extends beyond provenance to verifying what is actually installed. Controls such as lockfile pinning, dependency monitoring, and alerts on unexpected install scripts become increasingly important when a package arrives through an otherwise trusted channel.
If teams suspect a package may have been compromised, they should immediately audit recent dependency changes with tools like npm audit, review the affected package's change history, and investigate all recent install scripts. Activating incident response playbooks for supply-chain compromises, including isolating affected systems, capturing forensic data, and notifying key stakeholders, can help limit potential impacts while a full investigation is underway.
Source: @InfosecurityMag
3. Internal Audit, IT Audit & Continuous Control Monitoring
AI Policy Daily reported that President Trump and six technology executives signed a voluntary accord, under which participating companies commit to internal controls, independent audits, and board-level review of audit findings.
The significance lies in what the accord commits organizations to do and what it still leaves undefined. A commitment to retain an independent auditor and establish board oversight creates a governance structure. Still, the accord does not specify an audit standard, required scope, or an obligation to publish findings. Independent review and oversight may strengthen accountability, but the arrangement's effectiveness will ultimately depend on the criteria applied, the evidence reviewed, and how findings are addressed.
Source: @AIPolicyDaily
The Institute of Internal Auditors argued that internal audit plays an important role in overseeing AI-driven models by challenging assumptions, evaluating governance, and assessing whether controls remain effective as conditions change.
The key point is that approval does not equal continued effectiveness. Models evolve, business conditions change, data sources shift, and new risks emerge. A governance framework that is never retested can quickly become evidence of what was approved rather than of what still works. The value of internal audit therefore comes not only from reviewing the original framework but also from validating that governance, controls, and assumptions remain appropriate as the operating environment changes.
Source: @TheIIA
4. Identity Management / IAM
Dark Reading highlighted commentary from Ravi Sharma of Pitney Bowes, who argued that AI agents should be treated as privileged users and asked who is auditing their access.
The observation reflects a shift that many identity programs are beginning to encounter. An agent with standing access to systems, data, code repositories, or cloud resources functions as a security principal, just like a user, service account, or administrator. Access reviews that focus exclusively on human identities may overlook the permissions, privileges, and actions available to agent identities. The practical question is not whether the agent appears in the inventory. It is whether its access, activity, and accumulated permissions are reviewed with the same rigor applied to other privileged accounts.
Source: @DarkReading
PCWorld examined whether cloud-based passkeys can be trusted and noted that, while passkeys are often safer than passwords, they still require protection and backup.
The discussion highlights a broader identity-management principle. Authentication methods are only as resilient as the recovery and custody processes that support them. A passkey may improve protection against phishing and credential theft. However, organizations and individuals still need to decide where the credential is stored, how it is backed up, who controls recovery, and what happens if access to the primary device is lost. The key question is less whether passkeys are safer than passwords and more whether you define ownership and recovery before you need the credential.
Source: @pcworld
The same AI Policy Daily report discussed earlier in the audit section also has identity implications. The reported commitment by participating companies to use independent auditors and board-level review for AI controls introduces an oversight mechanism for systems that increasingly access data, applications, and business processes.
From an identity perspective, the accord's existence is not the main point. We expect that authority, accountability, and control over decisions about AI systems will be independently reviewed. As AI systems gain access privileges and decision-making capabilities, governance increasingly depends on whether someone outside the system can examine, justify, and challenge those permissions.
Source: @AIPolicyDaily
5. Cyber Insurance
Cyber Insurance News highlighted commentary from Andrew Horkan, chief executive of Cyber Tzar, on why many small businesses continue to treat security as a cost center rather than an operational requirement. The discussion focused on the idea that an organization can be compliant at one point in time and exposed shortly afterward.
The distinction matters because compliance and exposure measure different things. A completed assessment, certification, or audit may demonstrate that controls existed when they were reviewed. It does not guarantee that those controls continue to operate effectively as systems, users, vendors, and threats change. The underlying question is whether security is being managed as an ongoing business function or viewed primarily as a compliance expense.
Source: @CyberInsureNews
Insurance Journal highlighted an episode of Insuring Cyber featuring Mitch Cohen, founder of ClearLine, discussing the first 48 hours following a cyber incident and the communication challenges that often follow a breach.
The discussion highlights an area that technical response plans do not always address. Organizations may have forensic firms, legal counsel, incident-response procedures, and technical specialists under retainer, yet still struggle with basic communication decisions when an event becomes public. Who speaks to customers, regulators, employees, partners, and the media often becomes as important as the technical response itself. The growing interest from insurers suggests that communication readiness is increasingly being viewed as a factor that can reduce overall loss severity rather than simply a public-relations activity.
Source: @ijournal
Weinstein + Klein examined whether existing cyber-insurance policies adequately address risks created by AI agents and linked the discussion to questions around contracts, safeguards, and insurance coverage.
The issue is not whether an AI agent can create liability. It is whether current policy language was written with that scenario in mind. Many cyber policies were developed around human actions, employee mistakes, third-party intrusions, or system failures. As organizations authorize agents to access data, interact with systems, and make decisions, coverage questions increasingly depend on how policies, contracts, and liability provisions define responsibility for those actions. Reviewing the insurance policy and the underlying contractual obligations together may become an important step before an agent-related incident occurs.
Source: @weinstein_klein
6. Data Protection
Kohei Kurihara highlighted a report from Recorded Future News stating that a New Mexico jury found Meta deceived consumers about its data privacy practices.
A deception finding focuses on what users were led to believe about how their information would be handled. Privacy disputes often involve technical controls, policies, and disclosures, but deception findings center on whether the organization's representations matched its practices. In this case, although the report did not specify exact remedies or penalties, such findings can result in financial damages, requirements to improve privacy practices, or additional oversight. The cited information did not include details on the verdict’s penalties or any mandated corrective actions.
Source: @kuriharan ce: @kuriharan
The Calyx Institute highlighted an FTC lawsuit alleging that Hims & Hers shared customers' health information with third parties, including Meta and Snap, without consent.
The allegation centers on a core privacy principle: disclosures involving health information typically require demonstrating that the required consent was obtained. When health data is transmitted to advertising or analytics platforms, the operational question often becomes whether consent was collected, documented, and retained in a way that can be demonstrated later. If organizations cannot demonstrate consent, the disclosure itself becomes the central issue.
To support compliance, organizations should take practical steps, including establishing clear consent workflows and maintaining detailed records of consent forms, timestamps, and proof of data subject agreement. Regular audits of consent records, clear communication with individuals about data use, and consent management systems can further strengthen documentation and retention practices. These actions help demonstrate compliance during regulatory scrutiny or investigations.
Source: @calyxinstitute
The European Ethereum Institute summarized the second part of the European Data Protection Board's anonymization guidelines, which are open for consultation until October 30.
The guidance emphasizes that anonymization is evaluated against the means that are reasonably likely to be used, including available technology, cost, time, effort, and other accessible information. The analysis is not limited to an organization's internal capabilities; it also considers capabilities that an organization could reasonably obtain from external parties. The guidance further notes that contractual restrictions do not replace technical protections. A dataset described as anonymous must still withstand tests for record isolation, linkage, and inference. The practical challenge is therefore not what the dataset is called, but whether a recipient could realistically re-identify individuals using available means.
Source: @EuEthInstitute
7x. Enterprise Digital Risk Products
Rod Trent highlighted new Microsoft Entra support for signing in to Microsoft applications using passkeys issued by external identity providers. The significance isn't the passkey itself but the expanded trust relationship. Each external provider accepted for authentication becomes part of the sign-in chain and the organization's identity boundary.
The practical governance question is which identity providers are trusted to issue those credentials and how that trust can be revoked when circumstances change. Adding another issuer can improve flexibility and the user experience, but it also introduces another dependency that must be governed, monitored, and periodically reviewed.
Source: @rodtrent
Microsoft Mechanics described an approach that replaces legacy VPN access with identity-driven access through Microsoft Entra, using authentication, Conditional Access policies, and multifactor authentication, with Global Secure Access applied before a user reaches the target resource.
The shift changes where the control decision occurs. Traditional VPNs primarily establish a network path and then rely on downstream permissions. An identity-centric approach evaluates who is requesting access, under what conditions, and whether policy requirements have been met before the connection reaches the application, service, or system. For organizations modernizing remote access, the strategic question is less about replacing a VPN and more about determining whether identity has become the primary control point for access to business resources.
To help organizations meet these anonymization standards, they can take a few practical steps: conduct thorough risk assessments to identify potential re-identification methods, apply a combination of technical measures, such as data masking and aggregation, test the dataset against realistic attack scenarios, and regularly review anonymization methods as technology evolves. Integrating anonymization into data-processing workflows and maintaining evidence of decision-making can further demonstrate compliance during any regulatory review.
Source: @MSFTMechanics
Closing Thoughts
A common theme emerged across nearly every topic this week: organizations can collect information, but information alone does not provide assurance.
Across governance, cybersecurity, audit, identity, privacy, insurance, and enterprise technology discussions, the challenge was rarely a lack of data, controls, reports, inventories, or monitoring capabilities. Instead, the recurring question was whether organizations could explain how they made a decision, who owned the outcome, what assumptions underpinned it, and whether those assumptions remained valid as conditions changed.
That challenge appeared in various forms throughout the research. GRC programs were asked to demonstrate the evidence behind their conclusions rather than report an opinion. Third-party risk programs were challenged to determine whether vendor assessments remained accurate as attacker capabilities evolved. Audit functions were asked to reconstruct authority and control effectiveness between review cycles rather than rely exclusively on point-in-time testing. Identity teams were asked to demonstrate not only who received access but also why it was granted, how it was used, and whether it was removed appropriately. Privacy teams faced similar questions about data access, transfers, and exposure. In contrast, security teams were reminded that many controls are effective only when they remain independent of the systems they are intended to govern.
Many of the examples also pointed to a common operational reality. As AI systems, agents, SaaS platforms, cloud environments, and interconnected business processes continue to expand, organizations increasingly manage dependencies that change faster than traditional governance and review cycles can keep up with. Controls that appear effective during an assessment may drift. Permissions may accumulate. Vendors may become more exposed. Access paths may expand. Data may become reachable by people, systems, or jurisdictions not part of the original review.
The organizations most likely to manage that complexity successfully will not necessarily be those with the largest control libraries, the most detailed policies, or the greatest volume of reporting. They will be the organizations that consistently connect decisions to evidence, ownership to accountability, and controls to the outcomes those controls are intended to influence.
Across all seven sections, the most useful questions remained remarkably consistent:
What changed?
What dependency are we relying on?
Who owns the outcome?
Can we produce the evidence to support that answer?
Organizations that can answer those questions clearly are increasingly demonstrating understanding rather than activity. In an environment defined by accelerating change, expanding dependencies, and growing autonomy, that distinction is becoming one of the most important indicators of resilience.