SOP Development

A policy states a principle — for example, 'all payments above a set amount require dual approval.' A job description lists a role's general responsibilities. An SOP is the specific, sequential instruction set that operationalises the policy into repeatable action: who raises the payment request, on what form or system screen, who provides the first approval, at what threshold a second approval is triggered, and what evidence is retained once the payment is released. It is written to be followed step by step by whoever is in the role, not just understood in principle.

We prioritise by risk, not by department order: processes that are currently dependent on a single person with no written fallback, processes connected to a recent error or audit finding, and processes a bank, investor or auditor is likely to test soon typically go first. A business with limited budget for a first phase is better served documenting five high-risk processes thoroughly than twenty processes superficially.

Both, but sequenced deliberately. We first document how the process is actually being performed, because an SOP built on an idealised version that nobody follows is worse than no SOP — it creates a false sense of control. Where the walkthrough reveals a genuine control gap or inefficiency, we recommend a specific fix and document the improved version, but the improvement is agreed with management and the executing staff, not imposed as an assumption from day one.

Department heads often describe the process as designed rather than as executed — they are frequently one or two steps removed from the day-to-day exceptions, workarounds, and shortcuts that have crept in over time. The staff actually performing the process know exactly where the real friction points and informal adjustments are, and an SOP built without their input tends to be technically accurate but practically unusable.

Several core finance processes — invoice issuance and record-keeping, VAT return preparation, Corporate Tax data collation — have specific evidentiary requirements under Federal Decree-Law No. 8 of 2017 and Federal Decree-Law No. 47 of 2022, with record retention obligations set out under Ministerial Decision No. 114 of 2023. PNPC builds these requirements directly into the relevant SOPs — specifying exactly what evidence must be retained and where — so the process itself produces an audit-ready trail rather than requiring a separate reconstruction exercise if the Federal Tax Authority later raises a query.

It is built in as part of the same engagement. While documenting each process, we specifically identify where a single individual currently holds incompatible responsibilities — for example, the same person raising a purchase order, approving it, and processing the payment — and design the approval structure the SOP documents to separate those responsibilities appropriately, sized to what the business can realistically staff.

For a first tranche of five to eight priority processes, a full discovery-to-rollout cycle typically takes six to seven weeks. A larger SOP library spanning multiple departments, branches, or entities is scoped and delivered in phases rather than attempted all at once, prioritising the highest-risk processes in the first phase.

PNPC scopes and agrees a fixed fee based on the number of processes, the number of branches or entities executing them, and the complexity of the control review required — confirmed in writing before work begins. A single-entity business documenting five core finance processes is a materially different scope from a multi-branch retail group documenting operational, finance, and compliance processes across several locations.

Yes, and this is common. PNPC reviews existing manuals, policy documents, or informal process notes as a starting point, tests them against how the process is actually being performed, and updates or rewrites only where a genuine gap or drift is found — rather than discarding usable existing material and starting over unnecessarily.

Adoption is built into the engagement, not left to the handover meeting. Draft SOPs are walked through with the executing staff before finalisation, a short training session accompanies rollout, and the first live process cycle after rollout is checked against the SOP to confirm it is actually being followed and that the specified evidence is being generated — with any gap corrected immediately rather than discovered months later.

PNPC flags this explicitly and distinguishes it from the documentation task. If a process has too many unnecessary steps, duplicated approvals, or a structure that no longer fits the business's current scale, that is a process redesign question best addressed through PNPC's Business Process Re-engineering service, scoped separately or as a preceding phase, with the SOP then documenting the improved process rather than formalising an inefficient one.

Material changes — a new system, a changed approval threshold, a new regulatory requirement, a restructured team — warrant an SOP update as soon as practical. Minor cosmetic changes (a renamed field, a reorganised menu in the same system) are typically captured at the next scheduled periodic review rather than triggering an immediate rewrite, to avoid version-control churn that outpaces the business's ability to keep staff current on the latest version.

Yes, this is one of the most common drivers. PNPC documents a single master SOP for each core process and confirms it is adaptable to location-specific realities (different branch size, different local staffing) without losing the core control points that must remain consistent group-wide — so customers, auditors, and management get the same experience and the same evidence trail regardless of which branch executed the transaction.

For groups spanning a UAE entity and an India-linked parent, subsidiary, or sister entity, PNPC coordinates SOP development for cross-border processes — intercompany invoicing, consolidated reporting handover, shared-service arrangements — across our Dubai and India offices as a single team, so the SOP correctly reflects both sides of the handover rather than being written from only one jurisdiction's perspective.

Both models are available. Some clients engage PNPC for a defined discovery-to-rollout project and then manage the resulting SOP library independently, with periodic internal reviews. Others prefer PNPC to remain engaged for scheduled periodic reviews (typically every 6 to 12 months) and ad hoc support whenever a new process, branch, or system is being added.

BPR asks whether a process should change — fewer steps, different ownership, a new system, a redesigned workflow — and is a diagnostic and redesign exercise. SOP Development documents and controls a process as it is designed to run, whether that design is the existing process (formalised as-is, with control gaps closed) or a newly redesigned process following a BPR exercise. Many clients engage both in sequence: BPR to redesign, then SOP Development to lock the new design in as a written, trainable, auditable procedure.

Due diligence teams routinely test whether a business's operations run on documented, controlled processes or on informal, person-dependent practice — the latter is a specific red flag because it signals key-person risk and inconsistent execution that a new owner would inherit. A business with a current, well-adopted SOP library can demonstrate operational maturity and control discipline significantly faster than one assembling process documentation for the first time under diligence pressure.

At minimum, the process owner (usually a department head) and the staff who actually execute the process day to day need to participate in the walkthrough and the draft review. For finance and compliance processes, whoever owns the VAT filing, Corporate Tax data collation, or WPS payroll processing relationship should also be involved, since those processes carry specific evidentiary requirements the SOP needs to reflect accurately.

Where requested, yes. PNPC can run an initial training session for existing staff as part of the rollout phase, and the finalised SOPs themselves are written to double as a standalone onboarding tool for future new hires — reducing how much shadowing and informal on-the-job learning a new employee needs before they can perform the process independently and correctly.

The default deliverable is a structured written document per process (step-by-step, with named roles, forms, approval thresholds, and evidence points), typically maintained in a shared, version-controlled location the client controls. Where a client's system supports embedded workflow rules (an approval routing feature in the accounting or ERP platform, for example), PNPC can advise on configuring the system to enforce the documented control directly, though that configuration work itself may be scoped as a related but separate task.

Every control point built into an SOP is tied to a specific, evidenced risk found during the walkthrough — a real error pattern, a genuine audit exposure, a specific segregation-of-duties gap — rather than added as generic best practice for its own sake. Where a recommended control feels disproportionate to the business's actual scale, we discuss it directly with management before finalising, and the final document explains why each control point exists.