#Policy Framework: Index, Ownership and Control Mapping

POL-GL-000 | Version 1.0.0 | Last Modified On 31 July 2026 | Tier: Public

---

#Applicability

---

#Purpose

This document is the index to Edsol Edtech Pvt. Ltd.'s internal information security policy set. It states what policies exist, who owns each one, how often each is reviewed, how exceptions are granted, and how the set maps to ISO/IEC 27001:2022 Annex A and to the SOC 2 Trust Services Criteria.

It is published because Edsol Edtech Pvt. Ltd. holds no security certifications. A hospital evaluating Pensieve Labs cannot read an auditor's opinion, so it is given the underlying material instead: the actual policies, in full, with the maturity of each one stated honestly. A policy that describes a control Pensieve Labs does not yet operate is marked as a stated target with a date, never as a control in operation.

How to read this set. Every policy statement in every document listed below is written so that a reader can design a test for it. Where you can not design a test for a statement, that is a defect in the document. Report it to info@pensievelabs.org and it will be corrected in the next revision.

---

#1. The hierarchy

flowchart TD
  A["POL-GL-100<br/>Information Security Policy<br/>(apex, approved by the Founder)"] --> B["Domain policies<br/>POL-GL-101 … POL-GL-135"]
  B --> C["Standards<br/>POL-GL-130 hardening baselines"]
  B --> D["Runbooks<br/>RBK-GL-0xx: how a control is executed"]
  B --> E["Registers<br/>REG-GL-2xx: the evidence a control ran"]
  A --> F["Public disclosures<br/>WPR-GL-001, DIS-GL-0xx: what is told to customers"]
  A --> G["Contractual commitments<br/>MSA-IN-001, DPA-GL-001, SLA-GL-001, ADD-GL-001"]

Text description. The Information Security Policy (POL-GL-100) is the apex document and is approved by the Founder. Beneath it sit the domain policies POL-GL-101 to POL-GL-135. Beneath those sit standards (the hardening baselines in POL-GL-130), runbooks (RBK-GL-0xx, which say how a control is executed) and registers (REG-GL-2xx, which hold the evidence that a control ran). The apex policy also governs the public disclosures (the Security Whitepaper WPR-GL-001 and the DIS-GL-0xx series) and the contractual commitments in the Master Services Agreement, Data Processing Agreement, Service Level Agreement and Security Addendum.

Four layers, four different jobs:

Precedence. Where a policy in this set conflicts with a contractual commitment to a specific hospital, the contract prevails for that hospital and the conflict is raised as a policy exception under Section 5. Where a policy conflicts with a statutory obligation, the statute prevails and the policy is amended within 30 days.

---

#2. The policy register

Every doc_id below is addressable, published at https://trust.pensievelabs.org/documents/<doc_id>, and carries its own review date. Cadence is the maximum interval between reviews; a material change to the Platform, the threat environment or the regulatory position triggers an earlier review.

Owner role codes are defined in Section 3. At Edsol Edtech Pvt. Ltd.'s current size one person may hold more than one role; POL-GL-127 states which role pairs may not be held by the same person for the same transaction.

POL-GL-130 is the only document in this set that is not public. A hardening standard states the exact configuration of the defences; publishing it hands an attacker a map. It is released under the click-through mutual NDA (NDA-GL-002) to any hospital that asks, and its existence, scope and review date are public , which is the part a buyer needs.

---

#3. Roles

Edsol Edtech Pvt. Ltd. is a small company. These are roles, not headcount. One person may hold several; the constraint on which combinations are permitted is POL-GL-127.

Named holders are not published. Role holders are named in the internal REG-GL-201 Asset Register entry for the ISMS and are disclosed to a hospital on request under NDA-GL-002. Publishing the names of the individuals who hold production access on a public page would be a control weakness, not transparency.

---

#4. Approval, review and version control

4.1 POL-GL-100 is approved by R_FOUNDER. Every other policy in this set is approved by its named owner in Section 2 and countersigned by R_FOUNDER on first issue and on any change to a numbered policy statement.

4.2 Every policy carries version, last_modified_on and review_due_on in its frontmatter, and renders all three on every printed page.

4.3 A policy is reviewed on or before its review_due_on. The review is recorded with the reviewer, the date, and one of three outcomes: no change, editorial change (version patch increment), or material change (version minor or major increment, with a change-history row stating what changed).

4.4 A policy past its review_due_on is flagged on the internal staleness dashboard, and after 30 days overdue the public document page shows the true age rather than concealing it. A trust centre full of documents that quietly aged is worse evidence than one that admits a review slipped.

4.5 An out-of-cycle review is triggered by any of: a Sev-1 or Sev-2 incident; a change of cloud provider or of a sub-processor handling customer data; a new statutory or contractual obligation; a material change to the Platform architecture; or a finding from a penetration test, VAPT or customer audit.

4.6 Superseded versions are retained for retention_years and remain retrievable. A hospital that relied on a policy statement during its evaluation can obtain the version that was current on the date it evaluated.

---

#5. Exceptions

No policy in this set survives contact with reality unamended. The mechanism is therefore explicit rather than informal.

5.1 An exception is requested in writing to the policy owner, stating: the policy statement to be excepted, the business reason, the scope (systems, tenants, people), the compensating control, the residual risk, and the expiry date.

5.2 Every exception has an expiry date. An exception without an expiry date is refused. The maximum initial term is 90 days; renewal requires a fresh assessment, not a rubber stamp.

5.3 Approval authority:

5.4 Every exception is recorded in the Exception & Waiver Register (REG-GL-210) with the requester, approver, scope, compensating control, residual risk, grant date and expiry date.

5.5 Open exceptions are reviewed at every management review. The count of open exceptions and the count of expired-but-unclosed exceptions are both reported. The second number is the one that matters.

5.6 A hospital may request the count and category of open exceptions affecting its own deployment. The answer is given within 5 business days.

---

#6. Maturity: stated honestly

A policy set that describes a company larger than Edsol Edtech Pvt. Ltd. actually is would be worse than no policy set, because the first hospital audit would find the gap and every other statement would become suspect. Each policy therefore separates operating controls from stated targets, and this section carries the summary.

6.1 What is operating today. The controls described in WPR-GL-001 Section 2 to Section 15, access approval with a second person, time-bound production access, immutable audit logging, mandatory peer review, branch protection, dependency and secret scanning, encrypted backups, CMEK, the four-hour breach notification commitment, the published vulnerability disclosure policy, are implemented and in use. They have not been independently audited.

6.2 What is a stated target. The following are written into the policies as commitments with dates, and are marked in the policy text as targets rather than as operating controls:

WPR-GL-005 carries the live status of every row. Where WPR-GL-005 and this index differ, WPR-GL-005 is correct, because it is updated more often. A missed target is re-dated in public with a reason.

6.3 What is structurally limited by company size. Three limits are stated in the policies themselves rather than compensated for with language:

1. No 24×7 staffed security operations centre. Monitoring and alerting run continuously and route to an on-call engineer. POL-GL-113 says so.
2. Limited segregation of duties. The same small group builds and operates the Platform. POL-GL-127 states which separations are enforced, which are not achievable, and what compensates.
3. No independent internal audit function yet. POL-GL-100 Section 9 carries the target date.

---

#7. Mapping to ISO/IEC 27001:2022 Annex A

Edsol Edtech Pvt. Ltd.'s controls are mapped to ISO/IEC 27001:2022 Annex A. Edsol Edtech Pvt. Ltd. is not certified to ISO/IEC 27001. No accredited certification body has assessed this policy set or the controls behind it. The mapping below exists so that a hospital's assessor can navigate the set using a framework they already know, and so that the Statement of Applicability (STM-GL-010) can be produced against a set that is already aligned. The target date for certification is Roadmap iso27001 target.

A.5: Organisational controls (37)

A.6: People controls (8)

A.7: Physical controls (14)

A.8: Technological controls (34)

---

#8. Mapping to the SOC 2 Trust Services Criteria

Edsol Edtech Pvt. Ltd. holds no SOC 2 report of any type. No licensed practitioner has issued an opinion on the design or operating effectiveness of these controls. The target date for a SOC 2 Type I is Roadmap soc2 target. This mapping exists so that a reviewer working from a SOC 2 checklist can find the corresponding policy.

---

#9. What this set deliberately does not claim

1. It does not claim certification, attestation or independent audit of any kind.
2. It does not claim a 24×7 staffed security operations centre.
3. It does not claim full segregation of development from operations.
4. It does not claim controls over infrastructure Edsol Edtech Pvt. Ltd. does not own. In DM-3 the hospital owns the cloud project; in DM-4 the hospital owns everything below the application. Each policy states where its writ ends.
5. It does not claim that publishing a policy makes the control effective. The evidence that a control ran is in the registers, and the registers are what a hospital should ask to see.

---

#10. Related documents

---

#11. Change history