by Darren Baker M.ISRM
Over the past year, my work supporting international engineering projects has taken me beyond traditional Threat Risk Assessments (TRAs) and into developing, implementing, and maintaining security posture and mobilization frameworks. Recent assignments in the Middle East and South America presented very different threats and operating environments, yet the frameworks developed to manage those risks shared much of the same foundation.
What stood out was not necessarily the differences in the threats, but how much of the work involved understanding the project, building relationships, gaining leadership support, and developing practical arrangements that people could actually use.
A completed risk assessment does not necessarily mean an organization is prepared to manage the risks it has identified. Translating those findings into operational arrangements requires engagement, judgment, and a clear understanding of how the project functions.
These experiences prompted me to reflect on several lessons worth sharing with colleagues in the security and risk management profession. Not because the principles are new, but because applying them in complex, changing environments reinforced their importance.
Both projects shared a common challenge. While personnel operated under the project owner’s security arrangements once at the project site, my client’s organization retained its own duty of care responsibilities throughout mobilization and demobilization.
Understanding Where Responsibilities Begin and End
On major engineering and infrastructure projects, particularly in mining and energy, project owners typically manage security within their facilities and operational boundaries. However, operating under the project owner’s security umbrella does not remove the engineering organization’s duty of care responsibilities.
Those responsibilities extend to understanding the risks associated with getting personnel into a country, moving them between airports, accommodations, offices, and project sites, and ensuring arrangements exist to get them home again.
I describe this as the responsibility from the airport to the fence, and back again.
In the Middle East, the considerations included regional instability, travel restrictions, personnel accountability, and contingency arrangements. In South America, greater attention was required for movements between transportation hubs and remote project locations.
The threats were different, but the framework’s backbone remained consistent: defined responsibilities, movement controls, accountability, escalation triggers, and contingency arrangements.
The lesson was straightforward. We cannot assume the project owner’s security arrangements cover every aspect of personnel exposure. We need to understand where responsibilities intersect, identify gaps, and establish practical arrangements to address them.
Understand Leadership Intent Early
One of the more important lessons was the need to understand project leadership’s intent before developing the framework.
As security professionals, we naturally begin by assessing threats, vulnerabilities, and consequences. However, that assessment does not necessarily tell us how the project intends to operate.
Before developing controls, I needed to understand what leadership was trying to achieve, the operational flexibility required, and the decisions they expected the framework to support. A technically sound framework can quickly become impractical if it does not reflect how the project actually functions.
I found particular value in using 30%, 60%, and 90% development check-ins with leadership and key stakeholders.
At 30%, the focus is on confirming intent, approach, and assumptions. At 60%, it shifts to proposed controls, responsibilities, and operational practicality. The 90% review validates the overall framework, decision-making responsibilities, and any remaining gaps.
These were not simply progress reviews or opportunities to circulate documents for comment. They were working discussions that allowed assumptions to be challenged, proposed controls to be tested against operational realities, and leadership expectations to be confirmed.
An important part of these discussions was ensuring leadership understood the escalation triggers and decisions they might be required to make. Reviewing evacuation triggers, for example, does not necessarily mean recommending evacuation. It means establishing a shared understanding of the conditions that would warrant considering that decision, who has the authority to make it, and what the implications may be.
Leadership intent also needs to be revisited. Project priorities change, personnel numbers fluctuate, and security conditions evolve. Regular engagement keeps the framework aligned with operational requirements.
Relationships Matter
One of the more valuable lessons was the importance of developing genuine working relationships with the project team.
During the Middle East assignment, the Project Director invited me to spend ten days visiting the locations where the security framework would eventually be implemented. My initial thought was that much of the required engagement could be accomplished virtually. Interviews, document reviews, and discussions with key stakeholders could all be conducted remotely.
What I had underestimated was the value of being there in person.
Sitting at the same table, shaking hands, and taking the time to understand the people responsible for delivering the project proved far more valuable than I had anticipated. Those conversations provided insight into operational realities, competing priorities, and the concerns of decision makers that would have been difficult to appreciate through formal interviews alone.
More importantly, being present helped establish trust and a shared sense of responsibility for the framework we were developing.
I was no longer simply the security professional asking questions and producing a document. I had the opportunity to understand the people who would rely on the framework, while they could understand my approach, challenge assumptions, and contribute their own ideas.
That relationship created an environment where information flowed in both directions, in plain and simple language. Project leaders could speak openly about what concerned them, what kept them up at night, and where they saw potential problems. Some of the most useful information came from these conversations rather than formal reporting.
The experience reinforced why security plans should not be developed in isolation. Project managers, logistics personnel, site representatives, and administrative teams all hold information that can materially influence security planning. Without their input, we risk producing technically sound documents that fail to reflect how the project actually operates.
Those relationships become even more important when the security environment changes. Established trust makes it easier to have direct conversations, challenge assumptions, and discuss difficult recommendations that may affect project delivery.
The objective is not to compromise independent security judgment. It is to establish enough trust and understanding that our advice is heard, concerns can be raised openly, and practical solutions can be developed together.
Looking back, the ten days spent on the ground were as valuable to developing the framework as the technical assessment itself. Effective security planning depends not only on understanding threats and vulnerabilities, but also on understanding people and establishing shared responsibility for managing risk.
Write for the People Who Will Use the Plan
One challenge in our profession is balancing technical detail with practical usability.
Our audience often includes project managers, engineers, supervisors, and administrative personnel who are not security specialists. A security plan should not require security expertise to understand what action is expected.
I favour direct language, clear responsibilities, and straightforward instructions over unnecessary terminology.
An additional consideration when working internationally is using language that survives translation.
English may be the working language, but it is not necessarily the first language of those receiving or implementing security instructions. Complex sentences, idiomatic expressions, and ambiguous terminology can lose their meaning when translated.
Short sentences, consistent terminology, and clear instructions reduce the potential for misunderstanding.
This does not mean sacrificing technical detail. Supporting assessments must remain sufficiently comprehensive to justify recommendations and support decisions. The challenge is ensuring the reader can quickly understand what needs to happen, who is responsible, and when a decision must be elevated.
During a deteriorating security situation, clarity is an operational requirement.
A Framework Is Never Finished
Perhaps the most important lesson is that security frameworks must remain living operational tools rather than completed deliverables.
The changing security environment in the Middle East demonstrated how quickly assumptions concerning personnel movements, transportation availability, and contingency arrangements can become outdated.
As conditions evolved, it became necessary to revisit movement restrictions, personnel accountability arrangements, evacuation routes, and the triggers that could require leadership decisions.
A framework may be technically sound when approved and operationally inadequate weeks later if its assumptions are not continually validated.
Similar considerations apply in South America, where local conditions can influence how personnel are mobilized and how movement controls are implemented.
Maintaining a framework requires more than updating a risk rating. It means revisiting assumptions, validating routes and arrangements, reviewing responsibilities, and confirming that proposed actions remain achievable.
An unvalidated contingency route, outdated contact information, or an escalation process that leadership does not understand can create a false sense of preparedness.
The framework must also survive changes in personnel and leadership. If its effectiveness depends on one individual remaining involved, we have introduced another vulnerability.
Clear responsibilities, documented decisions, and shared understanding provide continuity.
Final Thoughts
My experiences in the Middle East and South America reinforced that effective security risk management involves more than identifying threats and recommending controls.
Despite the differences in the operating environments, both projects demonstrated that a consistent security management framework can be adapted to different threats and operational requirements.
The framework provides the structure. The threat assessment informs the controls. Leadership engagement and strong working relationships ensure those controls remain practical and relevant.
As security professionals, we need to understand our role and the limits of our decision-making authority. Our job is not to accept risk. Our job is to brief risk.
That means providing leadership with a clear understanding of the threats, potential consequences, available options, and recommended controls. The responsibility for accepting residual risk rests with those who have the appropriate authority and accountability for the project.
We should resist measuring the effectiveness of our work by the completeness of the documents we produce.
The real measure is whether the framework can be understood, implemented, maintained, and adapted when circumstances demand it.
That is where our professional value lies.
