Governance & Legal Framework

The authoritative governance, legal-mandate, inter-department coordination, RTI compliance, accountability, sustainability, and amendment framework for the Sindh IT Portal — Facilitation Desk (SITP).

1. Scope & How to Read This Document

This document is the single source of truth for the governance and legal framework of SITP. It answers four questions that the technical specifications do not, on their own, settle:

1. By what authority does the portal require departments to respond? (§3, §4)
2. Who decides, who is accountable, and who is informed across the company, S&ITD, the line department, the DG, and the Secretary? (§7)
3. How is performance measured, reported, and acted upon at the political and administrative apex of the province? (§6, §8)
4. How does the framework itself stay correct over time — funded, audited, RTI-compliant, and amendable? (§10–§17)

The document is consumed by the CM Office and SACM (for political ownership), the S&ITD Secretary (for operational ownership and chairing the steering committee), member department Secretaries and DGs (for MoU adherence and focal-person duties), the Sindh Information Commission (for RTI reporting), the Auditor-General and Public Accounts Committee (for audit readiness), and MAAHIR / Server4Sale (for vendor conformance). Where this document and the technical specifications diverge on a governance matter, this document governs.

1.1 Control format

Every governance requirement is written as a row in a per-domain table, mirroring the security catalogue's format (/specs/en/11-security-compliance/ §1.1):

1.2 Domain codes used in this document

2. Why Governance Matters

SITP is, by design, a single window through which IT companies raise complaints against any Government of Sindh department, with S&ITD acting as facilitator. The portal can route a ticket, start an SLA clock, and surface an escalation — but none of that compels a line department to act unless a legal mandate backs it. Without that mandate, inter-department compliance is voluntary, and the portal degenerates into a referral inbox that the receiving department is free to ignore. This is not a hypothetical risk; it is the documented lesson of every comparable system.

2.1 The CPGRAMS / DARPG precedent

The Government of India's Centralized Public Grievance Redress and Monitoring System (CPGRAMS), operated by the Department of Administrative Reforms and Public Grievances (DARPG) under the Cabinet Secretariat, is the gold-standard reference system for SITP (_context.md §1). CPGRAMS is effective precisely because DARPG did not rely on goodwill. Its efficacy rests on three governance instruments that SITP replicates:

The DARPG lesson is unambiguous: technology without mandate is inert. SITP therefore fronts every other capability with the legal-mandate and MoU instruments in §3 and §4. The remainder of this document exists to make that mandate operationally durable across changes of personnel, political cycles, and budget years.

2.2 Why-governance controls

3. Legal Mandate — S&ITD Notification & SOP

The legal mandate is the instrument that converts S&ITD's operational ownership into a binding obligation on line departments. It has two parts: a notification issued by S&ITD under the Rules of Business, Government of Sindh, and with the concurrence of the CM Office; and an accompanying Standard Operating Procedure (SOP) that operationalises the notification.

3.1 What the notification establishes

The notification is the legal hinge of the entire portal. Without it, S&ITD has no authority to compel a peer department to log in, assign, or respond. With it, non-response is a procedural lapse reviewable at the apex.

3.2 Draft notification outline

The notification shall be drafted in the standard S&ITD notification format and routed through the CM Office for concurrence. The outline below is the spec for the drafter; section numbers are the notification's, not this document's.

3.3 The SOP

The SOP operationalises the notification for day-to-day use. It is shorter and amended more frequently than the notification (§17). It covers, at minimum: how a Focal Person registers and onboards their department's users; how a ticket is received, assigned, and worked; how to record Awaiting Parties, On Hold, and resolution with proof; how to prepare and upload a MoM; how to participate in a TRI meeting; how RTI requests differ; how to handle sensitive/VIP tickets; how to read the department dashboard; and how to request an SLA override or raise a dispute under the MoU. The SOP is published in the Knowledge Base (module J) and is versioned.

3.4 Legal-mandate controls

4. Per-Department Memoranda of Understanding (MoUs)

The notification binds departments in principle; the MoU binds each department in operating detail. A separate MoU is executed between S&ITD and each member department. The MoU is the instrument that makes the portal's SLA, escalation, focal-person, data-sharing, and dispute provisions enforceable as between S&ITD and that specific department, in light of that department's structure, capacity, and regulatory posture.

4.1 MoU fields

Every department MoU records, at minimum, the following fields. The table is both the MoU template outline (§4.2) and the data dictionary for the department_mous configuration table.

4.2 MoU template outline (drafting structure)

The MoU is drafted against the following section sequence, mirroring the fields above. The template is maintained by S&ITD Legal.

1. Title, parties, recitals (reference to the notification).
2. Definitions.
3. Scope of cooperation (in-scope subject matters; out-of-scope per §9).
4. Roles and responsibilities of each party.
5. Focal Person and escalation contacts (named schedule).
6. SLA matrix and oversight powers (schedule).
7. Data-sharing, privacy, and sovereign-data handling.
8. Records, e-Office, and audit cooperation.
9. TRI meeting participation.
10. Reporting and policy-feedback cooperation.
11. Dispute resolution ladder.
12. Review, amendment, term, termination, and exit.
13. Schedules (Focal Person roster; SLA matrix; sensitive-category list; data-sharing matrix).

4.3 MoU governance controls

5. RTI as a Special Category — Sindh Transparency & RTI Act 2016

The Sindh Transparency & Right to Information Act 2016 gives every citizen a statutory right to request information from public bodies and imposes statutory deadlines that override the portal's generic SLA. SITP treats RTI as a first-class ticket category with its own routing, its own statutory SLA calendar, and its own reporting line to the Sindh Information Commission. This section states the statutory timers; the operational controls live in /specs/en/11-security-compliance/ §18 (SEC-060–SEC-064).

5.1 Statutory RTI timers

The following timers reflect the Sindh Transparency & Right to Information Act 2016 as commonly cited. The records officer shall confirm the exact section numbers and day-counts against the Act text before baseline freeze and cite the sections in the SLA configuration (open item, §17).

5.2 RTI routing & the Public Information Officer

When a filer selects the RTI category, the portal:

1. Routes the ticket to the named Public Information Officer (PIO) of the concerned department, recorded in department_mous / the org tree (module C). Each department's MoU designates its PIO (§4.1 #5).
2. Applies the statutory SLA calendar automatically — the 10 (+10) working-day response window — pausing on weekends and Sindh public holidays, and alerting the PIO before the deadline (near-breach at 80%).
3. Detects deemed refusal at statutory-window expiry and triggers the first-appeal right.
4. Tracks appeals through first appeal (head of body) and second appeal (Sindh Information Commission) on the same statutory calendar.
5. Exemptions: where the department lawfully withholds information under the Act, an authorised officer records the exemption with a reason; exemption decisions are audit-logged and are themselves appealable (SEC-064).

5.3 Reporting to the Sindh Information Commission

RTI compliance rates — on-time response percentage, deemed-refusal count, exemption usage, and appeal outcomes — are reported on the public transparency dashboard and in a periodic RTI compliance report submitted to the Sindh Information Commission (SEC-062). The report cadence aligns with the Commission's requirements and, at minimum, accompanies the annual Cabinet review (§6).

5.4 RTI governance controls

6. Governance Model

The governance model has four layers: political ownership (CM Office / SACM), strategic oversight (the Steering Committee), operational ownership (S&ITD Super Admin), and delivery (member departments + MAAHIR / Server4Sale). Escalation governance and a periodic review cadence bind the layers together.

6.1 Steering Committee

The Steering Committee is the strategic oversight body. It owns portal policy, approves material changes, reviews performance, and adjudicates disputes that have climbed the MoU ladder (§4.1 #15).

The Steering Committee meets quarterly (§6.4) and on an extraordinary basis when a matter has climbed the dispute ladder or when a security/major incident warrants apex attention.

6.2 Operational ownership — the S&ITD Super Admin

Day-to-day ownership rests with the S&ITD Super Admin role (see /specs/en/04-roles-permissions/), reporting to the Secretary S&ITD. The Super Admin:

• Owns global configuration: SLA defaults, escalation ladders, the holiday calendar, feature flags, notification templates, and all of the configuration tables enumerated in /specs/en/06-ticket-workflow/ §15.
• Onboards departments, seeds their MoU-driven configuration, and manages the Focal Person roster.
• Operates the trust-and-safety, abuse, and moderation functions (/specs/en/24-trust-safety/).
• Is the records officer for archival and disposal actions (§11, SEC-057).
• Convenes the monthly department review (§6.4) and prepares the quarterly steering pack and the annual Cabinet pack (§8).
• Holds the break-glass and privileged-access entitlements, subject to the quarterly recertification in /specs/en/11-security-compliance/ §21.

6.3 Escalation governance

The escalation ladder (/specs/en/06-ticket-workflow/ §6) is a notified structure (§3.1), not merely a configured one. Its governance properties are:

• Tier authority is configurable per department (notify-only vs action) but the existence of the ladder is fixed by the notification.
• Oversight actions (reassign, SLA override, force-resolve, directive letter) are themselves audited and surface on the steering pack, so that the apex can see how escalations were handled, not just whether they occurred.
• Repeat offenders (departments or officers with repeated escalations) are flagged for systemic-issue review and feed the policy-feedback loop (§13).
• Disputes between departments climb the MoU dispute ladder (§4.1 #15) and, if unresolved, reach the Steering Committee.

6.4 Review cadence

Performance review runs on a three-tier cadence that mirrors the DARPG monthly-review-plus-apex-dashboard model. Each tier has a defined artefact, audience, and decision rights.

Between cadences, the public transparency dashboard and the leadership digests (§8) keep performance continuously visible — the same continuous-visibility principle that makes the DARPG / PM-dashboard model effective.

6.5 Governance-structure diagram

Written description. Political ownership flows from the Cabinet and the CM Office down through the SACM, who chairs the Steering Committee. The Steering Committee — comprising the SACM, the Secretary S&ITD (convener and operational owner), the member department Secretaries, the S&ITD DG, and a non-voting MAAHIR representative — is the strategic oversight body that meets quarterly and reports annually to Cabinet. The Secretary S&ITD delegates day-to-day operations to the S&ITD Super Admin, who owns global configuration, onboards departments, runs the monthly department review, holds the records-officer duties, and is the operational counterpart to the member departments and to MAAHIR / Server4Sale. Member departments are bound to S&ITD by the notification in principle and by their MoU in detail, and report up through the monthly review and into the Steering Committee. Two external accountability relationships complete the model: the S&ITD Super Admin submits the periodic RTI compliance report to the Sindh Information Commission, and audit evidence (audit log, records, evidence packs) is available to the Auditor-General and the Public Accounts Committee on demand.

7. Roles & Accountability Matrix (RACI)

The RACI matrix below allocates Responsible / Accountable / Consulted / Informed across the five actor classes for the principal ticket-handling activities. Symbols follow standard RACI; "—" denotes no involvement. Where a single actor must be both R and A, the A is the answerable party and an R row is omitted.

7.1 Actor classes

7.2 RACI for ticket handling

7.3 RACI governance controls

8. Performance Reporting to Leadership

Performance reporting binds the governance model together by making department behaviour continuously visible — to the operating level monthly, to the strategic level quarterly, to the political apex annually, and to the public continuously. The principle, borrowed directly from the DARPG / CPGRAMS model, is that what is measured and visible gets done.

8.1 Reporting artefacts

8.2 Dashboards, digests, and public accountability

The reporting stack is built on the Analytics module (module I) and Metabase, with role-scoped dashboards (/specs/en/03-non-functional-reqs/ NFR-USA-002). Three properties matter for governance:

1. No self-certification. Departments cannot mark their own performance; the SLA engine and the audit log are the source of truth. A department's dashboard is a view of system-recorded facts, not an assertion.
2. Public accountability. Aggregate performance is public. A department with chronic breaches is visible to the citizens and companies it serves, mirroring the DARPG "Top 20 grievance-prone ministries" disclosure.
3. Traceability. Every figure on every report is drill-down to the underlying tickets and audit events, so leadership and auditors can move from a number to the evidence.

8.3 Reporting controls

9. Out-of-Scope Matters

SITP is bounded by design. Mirroring CPGRAMS' explicit exclusions, the following matters are out of scope and shall be refused at triage or returned to the filer with a redirect to the correct forum. The exclusion list is encoded in the notification (§3.2 §4) and surfaced in the public Knowledge Base so companies know what not to file.

9.1 In scope

Complaints and requests concerning an IT company's interaction with a Government of Sindh department, including but not limited to: unpaid dues and disputes with departments and their attached bodies; inspection, licensing, registration, and NOC delays; regulatory harassment; tax/NTN/SRB matters where a department's action or inaction is the grievance; EOBI and labour-related matters; investment-facilitation blockers; digital-services and e-government access problems; and RTI requests under the Sindh RTI Act 2016 (§5).

9.2 Out of scope (CPGRAMS-style exclusions)

9.3 Scope controls

10. Data-Sharing & Inter-Department Legal Basis

SITP routes tickets across departments and integrates with sovereign-data systems (NADRA, SECP, FBR, SRB, PSEB, NITB e-Office). Each of these data flows needs a legal basis and an undertaking by the receiving department. The legal bases are layered.

10.1 Legal bases for data sharing

10.2 Data-sharing controls

11. Records Management Legal Basis (Sindh Archives)

Tickets, MoMs, resolution certificates, and the audit log are official government records, not application data. Their lifecycle is therefore governed by the Sindh Archives rules and the records-management controls in /specs/en/11-security-compliance/ §16–§17, not by application convenience.

11.1 Records basis

The notification (§3.1) classifies SITP artefacts as official records. The retention schedule in /specs/en/11-security-compliance/ §16 governs retention windows; the archival workflow (SEC-055–SEC-059) governs the move to long-term storage with index preservation; and disposal is a documented, approved, audited action (SEC-057). Records subject to litigation, audit, or RTI hold are preserved until the hold is lifted (§16 ibid.).

11.2 Records controls

12. Sustainability & Funding

A portal that is not funded sustainably will atrophy; the DARPG lesson generalises. SITP's sustainability model rests on a provincial ADP budget line, recurring hosting and maintenance provision, an explicit exit/handover plan with the PPP vendor, and cost-recovery options that do not compromise free citizen access.

12.1 Funding instruments

12.2 Funding safeguards

• The core complaint and RTI right is always free. No cost-recovery instrument may charge a citizen or company for filing a ticket or exercising an RTI right. Any value-added fee schedule is approved by the Steering Committee and published.
• The PPP exit/handover plan (/specs/en/23-ppp-vendor-exit/) ensures S&ITD can continue operations across a vendor change; source-code escrow (SEC-075) protects continuity.
• Financial flows are auditable (SEC-074); PPP service fees follow tax-records retention.

12.3 Sustainability controls

13. Policy Feedback Loop

Recurring complaints are signals of policy failure, not merely service failure. SITP closes the loop by feeding patterns back into policy reform. This is the mechanism by which the portal evolves from a complaint-taker into a driver of structural improvement — a function DARPG performs through its periodic policy-advice notes to ministries.

13.1 The loop

1. Detect. The Analytics module (module I) flags recurring issues: a category with high volume and high repeat-offender rate across multiple companies, a department with chronic breach on a specific subject, a cluster of tickets pointing to a common regulatory friction. AI trend analysis surfaces candidates.
2. Triage. The Super Admin reviews flagged candidates each month and confirms which warrant a policy-feedback recommendation (filtering out one-off or company-specific issues).
3. Recommend. A policy-feedback recommendation is drafted, addressed to the concerned department (and, where cross-cutting, to multiple departments), proposing a specific reform (rule change, SOP update, fee schedule correction, regulatory simplification). The recommendation is recorded against the originating ticket cluster for traceability.
4. Refer. Recommendations go to the department Secretary at the monthly review; cross-cutting or significant recommendations go to the Steering Committee quarterly; major recommendations are included in the annual Cabinet report.
5. Track. Each recommendation has a status (open / accepted / enacted / rejected) tracked on the steering pack; enacted reforms are linked back to the originating cluster, and the portal measures whether the reform reduced the recurring issue.
6. Publish. Aggregate policy-feedback activity (recommendations made, accepted, enacted) is reported on the public transparency dashboard.

13.2 Policy-feedback loop diagram

Written description. The loop begins with detection: the analytics module mines tickets and the audit log for recurring clusters, chronic breaches on specific subjects, and repeat-offender departments, and the Super Admin triages these each month to confirm which are genuine policy candidates rather than one-offs. Confirmed candidates become draft reform recommendations addressed to the concerned department or, where cross-cutting, to several. The recommendations are referred upward on the existing review cadence — monthly to the department Secretary, quarterly to the Steering Committee, annually into the Cabinet report — and each recommendation is tracked to a terminal status with the enacted reform linked back to the originating cluster. The portal then measures whether the reform reduced recurrence, closing the loop empirically, and aggregate policy-feedback activity is published on the transparency dashboard so the public can see not only complaints handled but structural problems fixed.

13.3 Policy-feedback controls

14. Whistleblower / Anonymous Channel — Legal Protection

SITP provides a restricted-visibility anonymous / whistleblower intake channel (module K, /specs/en/24-trust-safety/) for reporting wrongdoing by a department or its officials where the filer fears retaliation. The legal-protection framework below governs that channel.

14.1 Legal protection framework

14.2 Whistleblower controls

15. Audit by AG / PAC Readiness

The portal must be audit-ready on demand for the Auditor-General (AG) and the Public Accounts Committee (PAC), as well as for internal audit and dispute resolution. The audit log and the records are the primary evidence; this section states the governance obligations that sit on top of the technical controls in /specs/en/11-security-compliance/ §20.

15.1 Audit-readiness obligations

• The audit log (aud_event) is append-only and hash-chained (SEC-042, SEC-044), exported off-host (SEC-046), and exportable on demand over a selectable date range with a signed manifest (SEC-072).
• Evidence packs — pen-test reports, the ASVS L2 assessment, the DPIA, CII registration, the IR plan, access-review records, the records/archival audit, the RTI compliance report, the financial-flow audit trail — are maintained by the Super Admin and produced on request (SEC-076).
• Records linkage to e-Office file movement lets an auditor trace a decision from portal ticket → official file → outcome (SEC-073).
• PPP-source-code escrow and the exit/handover plan protect auditability across vendor change (SEC-075).
• The Super Admin is the single point of contact for AG/PAC audit cycles, coordinating evidence production and acting on findings; the Steering Committee reviews audit outcomes quarterly.

15.2 Audit-readiness controls

16. Inter-Department Dispute Resolution

Disputes between SITP and a member department, or between two member departments over a ticket, climb a structured ladder before any external forum is sought. This protects the portal's collaborative basis and keeps resolution fast.

Disputes are logged in the audit trail with the tier reached and the outcome; chronic disputes feed the policy-feedback loop (§13).

16.1 Dispute controls

17. Amendment & Change Governance for This Specification

This document, its notification, its SOP, and the MoUs are all subject to change. The change-governance model below settles who may change what, with whose concurrence, on what cadence.

17.1 Amendment authority

17.2 Amendment principles

• Backward compatibility. Amendments shall preserve stable IDs (GOV-<nnn>, SEC-<nnn>, FR-<MOD>-<nnn>) — IDs are never renumbered or re-used (_conventions.md §4). Obsolete controls are marked superseded, not deleted.
• Audit trail. Every amendment to the specification, notification, SOP, or MoU is recorded in the audit log with old/new value, actor, and reason.
• Translation parity. A change to the EN master obliges a corresponding change to the UR and SD translations, tracked to completion (_conventions.md §2).
• Stakeholder notice. Material amendments are notified to the affected departments and, where relevant, to the public (for in-scope/out-of-scope or SLA changes that affect filers).

17.3 Change-governance controls

18. Control Catalogue Summary

18.1 MoSCoW distribution

19. Open Items [TBD/confirm]

End of document.