Pooyan Hamidi, CISSP, CCSP shares what data protection and artificial intelligence adoption taught him about designing security at the decision point.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
For years, I have worked on cybersecurity programs across healthcare, financial services and the public sector, focusing on data protection, identity, cloud collaboration and artificial intelligence (AI) security. One lesson has followed me across those engagements: knowing a security rule and applying it during a busy workday are two different things.
An employee may know that certain information is sensitive and still make a poor decision while rushing to share a document, grant access to a workspace or use an AI assistant. At that moment, security is rarely the employee’s primary task. The employee is trying to complete legitimate work under normal business pressures.
My focus here is the risk created by well-intentioned users: inadvertent disclosure, inappropriate sharing, excessive access or unsafe use of information. Malicious insiders and adversarial activity require different controls. Awareness training still matters because employees need to understand phishing, data handling, access control and their responsibilities. But I no longer believe training should carry most of the burden. In many situations, the best opportunity to influence behavior comes a few seconds before the risky action.
When Policy Meets the Workday
I have encountered this repeatedly in enterprise data protection programs. On one regulated engagement, the question sounded simple: What should happen when sensitive information is about to leave its intended boundary?
At first, a broad warning or blocking rule seemed appealing. Once we mapped the business workflows, the tradeoff became clearer. Some external sharing was legitimate because approved partners needed access. Other activities involved sensitive information where the wrong recipient or destination could create material exposure.
My role was to help translate the policy objective into a control design that people could work with. We considered the sensitivity of the information, the intended audience, the access context, whether the destination was approved and the likely consequence of a mistake. That led to a risk-response ladder:
- Allow: Activity is expected and presents low risk
- Warn: User needs additional context before proceeding
- Justify: Activity may be legitimate but warrants an intentional decision and a documented reason
- Block: Potential consequence or policy requirement should not be left to user discretion
The model did not eliminate user judgment. It concentrated judgment where it was useful. It also gave the security team a more practical basis for tailoring controls to business context instead of applying the same warning or block to every scenario.
A Warning Should Help Someone Make a Decision
I have also learned that the wording of a security intervention matters almost as much as the policy behind it. "This action violates organizational policy" may be accurate, but it tells an employee very little about what to do next.
A useful intervention should answer three questions: What is happening? Why might it be risky? What is the safer next step?
For example, when someone is about to share sensitive information outside the organization, the prompt should explain the concern and help the sender verify the intended audience or approved sharing method. Where appropriate, it can also suggest removing unnecessary sensitive information before proceeding.
I think of these short, contextual prompts as micro-interventions. They supplement awareness training by connecting guidance to the decision itself.
This approach is consistent with the National Institute of Standards and Technology (NIST) Human-Centered Cybersecurity program, which emphasizes security that works in practice and accounts for stakeholders’ needs and behaviors. That principle matters because a control that works in theory can still fail when people cannot use it effectively in the context of their work.
Do Not Make the Employee the Control
The overall lesson I have learned from these programs is that it's important to involve employees in cybersecurity, but security architecture should not depend on employees making the perfect decision every time. People work under deadlines, become distracted, misunderstand context and look for workarounds when the approved path repeatedly gets in the way of legitimate work.
That design philosophy is also consistent with the broader principle behind the Cybersecurity and Infrastructure Security Agency’s (CISA) Secure by Design guidance: more responsibility for security outcomes should sit with the technology rather than being pushed entirely onto users. CISA’s guidance is directed primarily at technology manufacturers, not enterprise awareness programs. I apply the same underlying idea when designing internal workflows: do not make the safe path unnecessarily difficult and introduce friction only where the risk justifies it.
Identity programs already use this logic. We do not simply tell people not to access information they do not need while leaving permissions unnecessarily broad. We use least privilege, appropriate authorization and access governance to reduce unnecessary exposure. Data protection and AI security should follow the same principle.
Awareness explains why the safer behavior matters. Architecture should carry part of the burden of making that behavior easier.
AI Changes the Context, Not the Fundamentals
I encountered a similar issue while supporting AI adoption in a large public-sector environment with strict compliance requirements. The rollout involved a few thousand users. The immediate question was not simply whether employees could use AI. We needed to understand what organizational information those users could already access, how that access would carry into AI-assisted workflows and what information could appropriately be used in prompts.
AI does not fix weak access governance. In some architectures, it can make authorized information easier to discover, combine and summarize. If the underlying access model contains stale group memberships, overly broad permissions or overshared repositories, those weaknesses can become more consequential even when the AI system is honoring the permissions it was designed to enforce.
That changed the order in which I approach the problem. Before designing prompt warnings or other AI-specific controls, I first want to understand the data, permissions and sharing model. AI changes the interface and scale of the problem, but it does not remove the fundamentals. Identity, least privilege, classification and access governance still matter.
Another key distinction is between approved enterprise AI services and public or consumer AI services. A blanket instruction such as ‘never put confidential information into AI’ is too imprecise when an organization has approved enterprise AI tools with defined identity, contractual and security controls. The more useful question is whether the specific tool and use case are approved for the data involved. If that is unclear, the organization should provide an explicit approval or escalation path.
For higher-risk activity, a technical restriction may be appropriate. When the context is ambiguous, a warning or justification step may be enough. This risk-based approach is consistent with the NIST Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, a cross-sector companion to AI RMF 1.0 that helps organizations manage generative AI risks according to their requirements, priorities and risk tolerance.
AI can increase the speed and scale at which data and access decisions occur. That makes the decision point more important, not less.
Measure Behavior, Not Completion
Deployment is only the start. Once a warning or control goes live, I want to understand how people respond to it. Useful signals include warning frequency, override rate, repeat behavior, exception requests, concentration by business process and recurring collisions with legitimate workflows.
Override rate alone is not a risk score. A high override rate may indicate a poorly tuned policy, an unclear warning, a legitimate business process the design did not anticipate or genuinely risky behavior. Repeated high-risk activity after a clear intervention may point in the other direction and justify a stronger control. Numbers need context.
I would still track awareness completion, but I would not confuse it with evidence that risk has decreased. Completion tells me whether someone finished a course. It does not tell me whether that person made a safer decision at the point of risk. Behavioral signals provide a different view of whether the control and the awareness program are changing outcomes.
Start With Three Decisions
Organizations do not need to redesign every workflow at once. I recommend starting with three employee decisions that can create meaningful risk: sharing information outside its intended audience, granting access and using organizational information with AI.
For each decision, look at what the employee sees at the point of action. Does the person know the information is sensitive? Is the intended audience clear? Is the application approved and appropriate for this data and use case? Is the person’s access appropriate? If the person stops, is there an obvious safe alternative? Then determine whether the action should be allowed, warned, justified or blocked.
I have seen the same challenge across healthcare, financial services and public-sector engagements: organizations want stronger protection without making everyday work harder. The goal is not to add more warnings or roadblocks. It is to give people clear guidance, appropriate access and stronger controls only when the potential consequences are serious.
Cybersecurity awareness does not end when an employee closes a training window. The most useful awareness may arrive five seconds before the mistake.
Pooyan Hamidi, CISSP, CCSP, is a cybersecurity leader and consultant with over 10 years of experience, specializing in enterprise data protection, cloud security, identity and AI security. His work focuses on translating security and governance requirements into practical controls for large, regulated organizations across healthcare, financial services and the public sector.
.png?h=420&iar=0&w=420)
