At Security Level 1, a port may appear fully prepared—security controls are stable and operations are running smoothly.
But what if Security Level 2 or 3 is declared during peak vessel, cargo and workforce movement?
Screening must intensify. Access permissions may need to change. Surveillance priorities must shift. Field teams must act—without compromising emergency access, creating uncontrolled congestion or losing operational visibility.
Can every affected gate, restricted zone, control room and field post move to the authorised security posture as one coordinated operation? More importantly, can port leadership confirm that the transition has actually happened?
For many ports, certainty becomes difficult at precisely this point. The approved Port Facility Security Plan (PFSP) may be sound. Security teams may be trained, and substantial technology investments may already be in place. Yet the execution chain can remain fragmented: instructions travel through calls and messages, individual systems are updated separately, field acknowledgements arrive inconsistently, and no single view confirms which controls have transitioned and which remain pending.
Across our engagements with port authorities, this is where the most consequential gap repeatedly appears—not in the intent to escalate, but in the ability to translate an authorised instruction into coordinated, exception-aware and verifiable field action.
The question, therefore, is not simply whether the port has an escalation plan. It is whether the entire facility can enter the required security posture quickly enough to matter—and produce the evidence to prove it.
Want to examine this readiness across your port?
This article includes a 15-check assessment covering command and control, gate flow, restricted-zone access, surveillance coordination, evidence, and resilience.
EXPLORE THE 15-CHECK READINESS TEST ↓What changes when the security level changes?
Declaring a security level and achieving that security posture are not the same event. The declaration establishes what is required; the port must then activate the applicable measures across live operations.
The ISPS Code defines three security levels:
- Security Level 1 — Normal: Minimum appropriate protective security measures are maintained at all times through the port facility’s routine approved controls.
- Security Level 2 — Heightened: Additional protective measures specified in the approved Port Facility Security Plan (PFSP) are maintained during a period of heightened risk. Depending on the PFSP, this may require stronger screening, tighter access restrictions and intensified monitoring while regular port activity continues.
- Security Level 3 — Exceptional: Further specific protective measures are maintained for a limited period when a security incident is probable or imminent. The port facility must respond to and implement security instructions issued by the Contracting Government.
The real challenge lies in the transition. An instruction may reach the command room immediately, but gates, restricted zones, surveillance teams and field posts do not change posture automatically. Each applicable measure must be communicated, implemented and confirmed. Any location, device or action still pending must remain visible to those coordinating the response.
India has already faced this requirement at scale. In May 2025, the Directorate General of Shipping directed heightened Security Level 2 measures across applicable maritime facilities and Indian-flagged vessels. A subsequent advisory supported reversion to Security Level 1 while permitting facilities to retain Level 2 where local threat perception warranted it.
"The operational lesson is clear: a port must be prepared not only to escalate, but also to verify implementation, manage incomplete transitions and return to the appropriate security posture in a controlled manner."
Where the gap actually breaks
A security-level transition is only as strong as its weakest operational link:
Authorised security-level instruction → PFSP-defined measures → role and system actions → field enforcement → verified evidence
Every stage must remain connected. When execution depends on separate calls, manual updates and disconnected systems, the instruction may be valid—but its implementation can become delayed, inconsistent or difficult to verify.
Four breakdowns are particularly important:
Gate Congestion
Additional screening introduced during active vehicle and cargo movement can slow lane processing. Without planned diversion routes, inspection capacity and exception handling, queues may extend beyond the gate complex and interfere with emergency or essential access.
Delayed Access Restrictions
Revised permissions for employees, contractors, visitors or vehicles may not reach every relevant reader and guard post at the same time. Sensitive areas can therefore continue operating under earlier access rules while the transition is already underway elsewhere.
Operator Overload
Control-room personnel may have to interpret revised SOPs, switch between multiple applications, prioritise alarms and manually track field acknowledgements—all during the most time-sensitive stage of the escalation.
Evidence Gaps
Paper registers and separate databases can make it difficult to establish when the instruction was received, who authorised each change, which controls were updated, what exceptions remained open and when field implementation was completed.
These risks are not limited to landside gates. Depending on the approved PFSP and applicable instructions, a security-level change may also affect cargo and ship’s stores handling, restricted areas, waterside monitoring, nearby approaches and coordination at the ship–port interface.
"Security and throughput are therefore not competing concerns. Both depend on the same capability: moving the entire affected facility into the authorised security posture as one controlled operation—not as a series of disconnected actions pointing in roughly the same direction."
Why this matters now
Port escalation readiness is receiving greater regulatory and institutional attention. Four developments since December 2025 illustrate this shift:
| Development | Date | What it means for ports |
|---|---|---|
| Bureau of Port Security constitution announced | Dec 2025 | A dedicated statutory body for port and vessel security was announced under Section 13 of the Merchant Shipping Act, 2025, modelled on BCAS. Its establishment and transitional rollout continued through 2026. |
| CISF designated as RSO for port facilities | Dec 2025 | As an RSO, CISF was assigned responsibility for undertaking port security assessments and preparing security plans for port facilities. |
| CISF Technical Consultancy Wing formally authorised as RSO | May 2026 | The formal authorisation enabled CISF to undertake security assessments and prepare security plans for port facilities under the ISPS Code. |
| Direction on private security personnel | Jul 2026 | The Home Minister directed that only licensed private security agencies and CISF-trained private security personnel should be deployed for port security. |
These developments indicate a shift towards more coordinated national oversight and assessment, while each port facility continues to operate under its approved PFSP. This makes it increasingly important to test escalation readiness before an external assessment identifies gaps.
Regulatory requirement vs. technical execution
Each level’s manual bottleneck has a specific integration answer. The exact measures are port-specific; the table below maps where execution typically breaks against how integrated systems can close that gap.
| Security level | Manual execution bottleneck | Integrated execution support |
|---|---|---|
| Level 1 (Normal) | Separate checks and manual reconciliation at gates. | ANPR and RFID-assisted verification, permit validation and barrier-control integration where approved. |
| Level 2 (Heightened) | Guards interpret revised screening and access rules across live operations. | Authorised rule changes can update HEP, access and routing workflows; selected vehicles can be directed to inspection facilities (UVSS) where the port layout supports it. |
| Level 3 (Exceptional) | Field posts rely on calls, static lists or separate applications. | ICCC-supported orchestration can distribute approved tasks, apply zone rules, surface exceptions, and track acknowledgements, subject to human authority, applicable instructions, and safety controls. |
The four pillars of controlled escalation
Connecting the command room to field execution takes a four-part integrated control architecture, engineered so every change stays authorised, PFSP-aligned, exception-aware and verifiable. These four pillars map directly onto MSBU’s own solution architecture across Harbour Entry Automation and Access Management, Security and Surveillance, and Integrated Command Control, the architecture MSBU builds, not a generic framework assembled to fit the topic.
Pillar 1: Dynamic Gate Logic
Authorised rule changes applied at the gate without improvisation in live traffic.
Tighter screening at Level 2 creates an immediate operational binding: increased scrutiny while holding the line on gridlock. Where a Level 2 response calls for additional vehicle screening, the challenge is applying the approved rule while keeping guards working from a defined process rather than improvising in live traffic. A Harbour Entry Permit (HEP) system supports authorised rule changes: ANPR and RFID verify vehicle and permit context, while the gate workflow directs selected vehicles to UVSS or secondary inspection bays, where those controls form part of the approved process and the physical layout permits safe diversion.
Pillar 2: Rule-Based Physical Access Control
Zone-specific restrictions that preserve essential and emergency access automatically.
Restricting access at speed carries its own risk: tighten too indiscriminately, and essential personnel and emergency response get caught in the same net as the threat being screened for. At higher security levels, the PFSP may require tighter access to restricted areas such as berths, jetties, substations or control locations. An integrated PACS applies authorised, zone-specific changes across relevant readers and surfaces exceptions automatically, keeping essential personnel, emergency access and operational continuity governed by policy rather than left to a blanket lockdown.
Pillar 3: Command Layer and Surveillance Orchestration
A single command view that correlates events, assigns tasks and tracks acknowledgement.
The operator overload described above usually traces back to one thing: no single system doing what the architecture should handle on its own. An ICCC serves as the command layer, prioritising critical camera views after authorised confirmation, correlating VMS, PIDS, PACS and gate events through shared event references and synchronised time, presenting role-specific SOPs, assigning tasks, tracking acknowledgement and flagging devices or posts still mid-transition. Where integrations are deployed, validated intrusion alarms guide operators to the relevant camera view directly. Analytics settings and monitoring priorities change only through approved, tested rules, accounting for false alarms, cyber resilience and device limitations.
Pillar 4: Time-Stamped Audit Trails
A coherent event trail that proves exactly how the transition happened.
Executing the transition well is only half the requirement. A port also has to prove, afterward, exactly how it happened. A coherent event trail records when the instruction was received, who authorised each action, what rule changed, which field device acknowledged it and which exception remained open. This evidence supports audits and post-event reconstruction, and it works alongside correct implementation, trained personnel, functioning equipment, controlled exceptions and validation through drills and exercises to establish compliance.
These four pillars prove their value only when tested before they’re needed. The fifth element in the readiness framework, resilience and validation, checks exactly that: whether the architecture above has been drilled, verified and confirmed to hold under failure, as a discipline layered on top of the technology, not a fifth piece of it.
Architectural flexibility: greenfield and brownfield deployment
Controlled escalation accommodates more than one technology strategy:
- Greenfield port infrastructure: security-level workflows can be engineered into the foundational software, hardware, communications and ICCC architecture from the outset.
- Established brownfield facilities: serviceable barriers, access-control devices, CCTV, RFID and weighbridges can often be retained. A carefully engineered orchestration and integration layer connects them, addressing capability gaps and replacement priorities realistically, since legacy assets vary in what they can support. Approved manual fallbacks stay workable during equipment, network, power or communication disruption, with actions and records reconciled after recovery.
Six tests of security-level escalation readiness
Before an actual escalation happens, port leadership should test whether the approved plan can become controlled field action. The accompanying 15-check readiness test develops these six tests in practical detail:
| Test | What It Validates |
|---|---|
| The command-and-control test | Can the ICCC or designated control point distribute approved actions, including applicable Security Level 3 instructions, present current role-specific guidance and confirm field implementation? |
| The gate-flow test | Can the gate operation apply revised screening, diversion and exception-routing rules while protecting emergency access and keeping queues within the facility’s planned controls? |
| The access-control test | Can authorised zone and credential changes reach relevant readers and guard posts, preserve essential and emergency access, and support personnel accountability where required by approved emergency arrangements? |
| The surveillance-coordination test | Can validated alarms, camera views and heightened monitoring priorities stay coordinated while avoiding blind spots, false-alarm overload or unclear response responsibility? |
| The demonstrable-evidence test | Can the port reconstruct the instruction, authorisation, field enforcement, exceptions and closure as one time-ordered chain using a single platform or reliably reconciled records? |
| The resilience-and-validation test | Can approved measures continue through system or communication failure, and have escalation arrangements been tested through applicable drills or exercises with corrective actions tracked to verified closure? |
A No or Manual response points to a control worth testing against the PFSP, operational risk and available evidence before a real escalation, rather than an automatic finding of non-compliance.
Test your port’s escalation readiness
The fastest way to find out is to test it directly. The accompanying ISPS Security-Level Escalation: Technical and Operational Readiness Test turns the six tests above into 15 practical checks across command and control, gate flow, restricted-zone access, surveillance coordination, evidence, and resilience and validation.
Score your port honestly and write down your three priority gaps. That gives the port a genuine answer to whether escalation can be executed, tracked and verified—or whether confirmation remains fragmented across calls, registers and separate systems.
This is a focused technology-and-execution diagnostic, built by MSBU to support ISPS-compliant execution planning. It stands apart from a complete ISPS assessment, an IMO-issued checklist, a PFSP approval or a compliance certificate; actual compliance is assessed against the facility’s approved PFSP, applicable national requirements and instructions of the Contracting Government or Designated Authority. Completed copies can reveal security-sensitive weaknesses and deserve the same protection as any other sensitive security document.
From readiness to execution
Maritime Systems & Integration (MSBU), built on Mantra Softech’s 10 million+ hours of expertise across critical infrastructure, works across the full control chain an escalation exposes: understanding the port’s existing environment, retaining what still works, identifying what is genuinely missing, supplying the required hardware and software, and engineering the architecture around the intended security outcome.
Understand the existing environment → retain what works → identify genuine gaps → hardware, software and integration (OEM & SI) → engineer around the outcome
MSBU’s consultative approach reduces avoidable operational friction while strengthening a port’s ability to execute, sustain and prove its security controls, whether the gap surfaces in gate automation, access control, command-room coordination or evidence capture.
These capabilities are intended to support security controls and operational outcomes relevant to ISPS implementation. The exact requirement, design and acceptance remain dependent on the port facility’s PFSA, approved PFSP and applicable national requirements.
"The real measure of readiness is whether a port’s existing control system moves as one coherent chain the moment an authorised instruction arrives, securely, efficiently and ready for the next escalation when it comes. That is the test this piece opened with, and it’s the work that follows once the test is run."