A Project Manager’s Guide to Managing Security Risks in the Oil and Gas Sector

Oil and gas projects bring together people, equipment, technology and contractors in environments where disruption can have serious consequences. A security incident may interrupt operations, delay construction, damage assets or prevent a project team from reaching a remote worksite. Security therefore cannot sit outside the main project plan.

Table of Contents

For a project manager, managing security risks in the oil and gas sector means considering threats, vulnerabilities and response arrangements alongside cost, schedule, quality and safety. The project manager does not need to become a security specialist, but they do need to ensure that security requirements have owners, deadlines and sufficient resources.

The most effective approach begins early. When security is considered only after designs have been approved or contractors have arrived on site, the project may face expensive changes that could have been avoided.

Why Security Belongs in the Project Plan

Security is sometimes treated as an operational matter that begins after project handover. That view can leave important gaps in the finished asset. Decisions made during the project may determine where access points are located, how surveillance systems are connected, who can enter restricted areas, and how quickly people can respond to an incident.

If these requirements are identified late, the project team may need to change layouts, replace equipment, or renegotiate contracts. Security can also affect the project while work is still underway. Materials may be stolen from a construction site. Unauthorised people may enter controlled areas.

Contractors may unintentionally expose sensitive information. Community tensions or deliberate disruption may restrict access to a location. The project manager should bring security specialists into planning discussions before these risks begin influencing the project. Early involvement makes it easier to include appropriate controls in the project scope, budget and schedule.

Understand the Difference Between Safety and Security

Safety and security are closely connected, but they are not the same. Safety management generally addresses accidental harm, such as equipment failure, hazardous substances or unsafe working practices. Security management considers deliberate actions, including theft, sabotage, unauthorised access, violence and the misuse of information.

One event can involve both areas. For example, deliberate interference with equipment could create an immediate safety hazard and a longer operational shutdown. The project manager needs both safety and security specialists to examine the event from their respective perspectives.

Keeping separate risk categories can make ownership clearer. However, the project team should also review where those categories overlap. A project plan that treats each discipline as an isolated function may miss consequences that cross several parts of the organisation.

Begin With the Project Environment

A useful security assessment starts with the conditions in which the project will operate. A refinery upgrade, offshore installation, pipeline project and retail fuel development do not have identical exposures.

The project manager should work with relevant specialists to identify:

The assets, systems and information that require protection
People or groups that could intentionally cause disruption
Weaknesses that could make an incident more likely
The operational, financial and human consequences of an incident
Existing controls and the exposure that remains after those controls

Context matters. A control that is proportionate for a high-value processing facility may be unnecessary for a small project office. Similarly, a standard site security plan may not be sufficient for a project involving remote infrastructure, frequent contractor movements or valuable materials.

This assessment should not become a one-time exercise completed at project initiation. Conditions can change as the project moves from design to procurement, construction, commissioning and handover. Each stage introduces different people, assets and vulnerabilities.

Put Security Risks in the Main Risk Register

Security issues are easier to overlook when they are kept in a separate document that the wider project team rarely sees. Sensitive operational details may need restricted access, but the risks that could affect delivery should still appear in the main project risk process.

A disciplined project risk management process helps the project team identify threats, assess their likelihood and impact, assign ownership, and monitor the effectiveness of planned responses. Security risks should pass through the same governance process as engineering, commercial, and schedule risks.

Each entry should describe a specific event and its potential effect. “Site security” is too broad to support a useful decision. A clearer entry might state that repeated theft of electrical components could delay installation and increase procurement costs. The project manager can then agree on preventive action, contingency arrangements and escalation triggers. This turns a general concern into something the project team can manage.

Give Every Security Action an Owner

A security risk without an accountable owner can remain on the register for months without meaningful progress. The project manager should assign responsibility to someone with the authority and knowledge to act. The risk owner is not necessarily the person completing every task.

A security manager might own the risk while facilities, procurement, and information technology teams deliver individual controls. The project manager remains responsible for coordinating these activities with the rest of the project. Deadlines also need to reflect project dependencies. If an access control system must be working before commissioning begins, its design, procurement, and testing dates should appear in the integrated project schedule.

Calling the system a security requirement does not make it separate from the project timeline. For significant risks, the project manager should also establish clear escalation points. Senior decision-makers need to know when additional funding, a design change or a temporary pause may be required.

Include Contractors and Suppliers

Oil and gas projects often depend on several layers of contractors, subcontractors and specialist suppliers. Each organisation may bring its own staff, equipment, digital access and working methods into the project. The project manager should establish security expectations before contracts are awarded.

Relevant requirements may cover personnel screening, identification, access permissions, incident reporting, information handling and the return of passes or equipment when work ends. These controls need to be proportionate to the role. A contractor servicing a business system may create different exposure from a delivery driver entering a storage area.

Applying identical requirements to everyone can create unnecessary administration without addressing the highest risks. Responsibility should continue throughout the contract. The project team needs a reliable process for approving new personnel, changing access rights, and removing access when a person leaves. An accurate list at the start of the project will not remain accurate without regular updates.

Manage Physical and Digital Dependencies Together

Modern oil and gas facilities rely on connected operational and information systems. A physical security decision can therefore have digital consequences, while a cyber incident can affect activity at a physical site. For example, surveillance cameras, entry systems and monitoring equipment may depend on shared networks, remote connections or third-party support.

The project manager should make sure that security, engineering and technology teams review these dependencies together. This is particularly important when a project introduces new equipment or connects an existing facility to an external system. The project plan should allow time for technical review, access approval, testing and the correction of vulnerabilities before the system becomes operational.

Energy infrastructure is recognised as part of the wider critical infrastructure environment, where disruption may affect organisations and communities beyond the boundary of one facility. That wider consequence should influence how the project manager evaluates impact and prioritises protective work.

Prepare for Incidents Before They Happen

Preventive controls reduce risk, but no project can remove every possibility of an incident. The project manager should confirm what will happen if a serious event occurs during delivery. An effective response plan identifies who receives the first report, who makes urgent decisions, and how the project team communicates with employees, contractors, emergency services, and senior management.

It should also explain how critical project work will continue or restart. Plans become more useful when they are tested. A short tabletop exercise can expose practical weaknesses that are difficult to see on paper. The team might discover that contact information is outdated, authority is unclear, or an alternative worksite cannot support essential project activity.

The exercise does not need to recreate every detail of an emergency. It should give the project team a realistic situation, require participants to make decisions, and record the issues that need correction. The project manager can then assign actions and track them to completion.

Control Security Through Project Change Management

Project conditions rarely remain fixed. Designs change, deadlines move, and suppliers are replaced. Each significant change can alter the security profile. A new entrance may affect site access. A schedule extension may require security services for longer than budgeted. Replacing a local supplier could introduce unfamiliar personnel or transport arrangements.

A temporary technical solution may create access that was not part of the original design. Security review should therefore form part of the project change process. This does not mean every minor adjustment requires a full assessment. The project manager can define criteria that trigger additional review, such as changes involving critical assets, controlled areas, sensitive information, or external connectivity.

Recording these decisions also protects project continuity. If personnel change, the next project manager or security specialist can understand why a control was selected and what assumptions supported it.

Measure Readiness, Not Just Activity

A project report may show that security meetings occurred and equipment was ordered, but those activities do not prove the project is ready. More useful measures focus on whether controls work. The project manager might track unresolved high-priority risks, overdue security actions, access permissions awaiting removal, failed tests, or personnel who have not completed required training.

The project team should also monitor residual risk on an ongoing basis. Installing a control may reduce exposure without eliminating it entirely, and new vulnerabilities can emerge as conditions change. Decision-makers need to understand what risk remains, whether that level is acceptable, and what contingency arrangements are available if the risk materialises during delivery.

As handover approaches, the project manager should confirm that the operating team has received current procedures, system information, training records, and ownership of open actions. Security should be part of operational readiness, not a folder transferred after the main project has closed.

Final Thoughts

Security risk management works best when it is integrated into ordinary project management. The project manager identifies the right specialists, brings them into decisions early, and makes sure their requirements are reflected in the project scope, schedule, budget, and risk register.

Clear ownership, realistic incident exercises, and regular reviews help the project team respond as conditions change. Contractor access, connected systems, and operational handover also need deliberate attention rather than last-minute checks.

A project manager may not personally design every security control, but they play an essential role in making sure that security work happens at the right time. When that coordination begins early, the project is better placed to protect its people, maintain continuity, and deliver an asset that is ready for operation.