Search all 478 artefacts by title, document ID or content.
Questionnaire | Family 4, Assurance & Evidence
THIS IS A SELF-ASSESSMENT. It was completed by Edsol Edtech Pvt. Ltd. about Edsol Edtech Pvt. Ltd. No auditor, certification body or assessor has reviewed, tested or validated any answer in this document. Edsol Edtech Pvt. Ltd. holds no ISO/IEC 27001 certificate, no SOC 2 report and no CSA STAR Level 2 certification.…
This document is the source of truth for: caiq-answer-set, csa-star-level-1-submission, marketing:/trust/caiq
Those surfaces render this text from here. They do not keep their own copy, so they cannot drift from it.
Artefacts this one references or cannot be issued without.
Artefacts that would be blocked if this one were missing or out of date.
QRE-GL-005 v1.0.0, Last Modified On 31 July 2026, Tier: Public
THIS IS A SELF-ASSESSMENT. It was completed by
Edsol Edtech Pvt. Ltd.aboutEdsol Edtech Pvt. Ltd.. No auditor, certification body or assessor has reviewed, tested or validated any answer in this document.Edsol Edtech Pvt. Ltd.holds no ISO/IEC 27001 certificate, no SOC 2 report and no CSA STAR Level 2 certification. Treat every answer below as a management assertion that you are entitled to test.
The Consensus Assessments Initiative Questionnaire (CAIQ) is the Cloud Security Alliance's standard question set, aligned one-to-one with the Cloud Controls Matrix (CCM) v4: 197 controls across 17 domains. This document answers all 197, honestly, per deployment model.
It exists to remove a step from your evaluation. If your security reviewer would otherwise send
Pensieve Labs a spreadsheet and wait five to fifteen working days for it to come back, that round trip
is already done, and it is done in a format your reviewer can diff against every other cloud vendor they
have assessed.
Where the answer is "No", this document says No, names the compensating control, and gives a target
date. A questionnaire from an uncertified company with 197 affirmative answers is not evidence; it is
noise. See WPR-GL-005 Section 1 for why Pensieve Labs takes this position deliberately.
| DM-1 Dedicated | DM-2 Shared | DM-3 Customer Cloud | DM-4 On-Premise |
|---|---|---|---|
| Full | Full | With variance | Substantially different: read the variance column on every row |
Deployment models are defined in WPR-GL-004. DM-4 is the model in which most infrastructure controls
transfer to the hospital. An answer of "Yes" for DM-1 frequently becomes "CSC-owned" for DM-4, and
this document marks every such case rather than averaging them into a claim that is true for nobody.
| Code | Meaning |
|---|---|
| Yes | Implemented and operating today. Evidence exists and is named. |
| Partial | Implemented in part. The specific gap is stated in the same row. |
| No | Not implemented. A compensating control and a target date are stated in the same row. |
| Inherited | Delivered by the underlying cloud provider inside its own audited scope. Pensieve Labs configures, verifies and remains accountable to the hospital. |
| CSC | The control is the hospital's (the Cloud Service Customer's) under the applicable deployment model. |
| N/A | The control does not apply to Pensieve's service model. A justification is stated. |
These are the CSA's own values and are used unmodified.
| Code | Meaning |
|---|---|
CSP |
Cloud Service Provider owned: Edsol Edtech Pvt. Ltd. |
CSP-shared |
Owned by Edsol Edtech Pvt. Ltd., delivered on infrastructure operated by a third party |
Shared |
Shared between Edsol Edtech Pvt. Ltd. and the hospital |
CSC |
Cloud Service Customer owned, the hospital |
3rd-party |
Outsourced to a named sub-processor (see DIS-GL-009) |
| Field | Value |
|---|---|
| Assessed entity | Edsol Edtech Pvt. Ltd. |
| Service assessed | Pensieve, the hospital operating system, in deployment models DM-1, DM-2, DM-3 and DM-4 |
| Infrastructure in scope | Google Cloud Platform (Cloud Run, managed PostgreSQL, object storage, Cloud KMS, managed secret store) in the regions recorded on the Order Form as Deal data region |
| Corporate systems in scope | Source control, CI/CD, ticketing, identity provider, endpoint fleet |
| Explicitly out of scope | The hospital's own network, endpoints, clinical devices and staff; and, in DM-4, all infrastructure |
| Assessment basis | Management self-assessment against CCM v4 |
| Independent validation | None. Not CSA STAR Level 2. Not Valid-AI-ted at this version. |
| Next scheduled refresh | 31 July 2027 |
Every "Yes" in this document is traceable to a published artefact. The chain is:
| Layer | Artefact |
|---|---|
| What the control is | This document |
| How it works technically | Security Whitepaper WPR-GL-001 |
| Which model it applies to | Deployment Models WPR-GL-004 |
| What is contractually owed | DPA-GL-001, ADD-GL-001, SLA-GL-001 |
| Control-by-control ISO mapping | Statement of Applicability STM-GL-010 |
| What is not held at all | Trust & Assurance Overview WPR-GL-005 Section 6 |
| # | Domain | Controls | Yes | Partial | No | Other |
|---|---|---|---|---|---|---|
| 1 | A&A: Audit & Assurance | 6 | 1 | 1 | 4 | 0 |
| 2 | AIS: Application & Interface Security | 7 | 6 | 1 | 0 | 0 |
| 3 | BCR: Business Continuity & Operational Resilience | 11 | 7 | 2 | 1 | 1 |
| 4 | CCC: Change Control & Configuration Management | 9 | 8 | 1 | 0 | 0 |
| 5 | CEK: Cryptography, Encryption & Key Management | 21 | 16 | 3 | 2 | 0 |
| 6 | DCS: Datacenter Security | 15 | 0 | 0 | 0 | 15 |
| 7 | DSP: Data Security & Privacy Lifecycle | 19 | 14 | 3 | 2 | 0 |
| 8 | GRC: Governance, Risk & Compliance | 8 | 4 | 2 | 2 | 0 |
| 9 | HRS: Human Resources | 13 | 9 | 3 | 1 | 0 |
| 10 | IAM: Identity & Access Management | 16 | 13 | 2 | 1 | 0 |
| 11 | IPY: Interoperability & Portability | 4 | 4 | 0 | 0 | 0 |
| 12 | IVS: Infrastructure & Virtualisation Security | 9 | 7 | 1 | 0 | 1 |
| 13 | LOG: Logging & Monitoring | 13 | 10 | 2 | 1 | 0 |
| 14 | SEF: Security Incident Management & Forensics | 8 | 6 | 1 | 1 | 0 |
| 15 | STA: Supply Chain, Transparency & Accountability | 14 | 8 | 3 | 3 | 0 |
| 16 | TVM: Threat & Vulnerability Management | 10 | 5 | 2 | 3 | 0 |
| 17 | UEM: Universal Endpoint Management | 14 | 8 | 3 | 3 | 0 |
| Total | 197 | 126 | 30 | 24 | 17 |
24 controls are answered No. They are consolidated in Section 19 with compensating controls and target dates, so a reviewer who wants only the gaps can read one table.
The weakest domain in this assessment, and predictably so: it is the domain that measures independent
assurance, and Edsol Edtech Pvt. Ltd. has none yet.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| A&A-01 | Audit and assurance policy and procedures established, documented and reviewed annually | Partial | CSP | An assurance programme is documented in WPR-GL-005 and reviewed quarterly. A standalone audit-and-assurance policy with a formal annual approval record is not yet issued. Target Roadmap isms policy set target |
| A&A-02 | Independent audits performed at least annually | No | CSP | No independent audit has been performed. Compensating: a CERT-In empanelled VAPT engagement is scheduled (REP-GL-004), which is an independent technical assessment by a Government of India-empanelled organisation. ISO/IEC 27001 Stage 1 targeted Roadmap iso27001 target |
| A&A-03 | Risk-based planning of assurance activities, aligned to standards | Partial | CSP | Assurance activity is sequenced by the roadmap in WPR-GL-005 Section 5, which is risk- and market-driven and published with dates and owners. It is not yet governed by a formal audit plan |
| A&A-04 | Verification of compliance with all relevant standards, regulations and contractual requirements | No | CSP | No third party verifies compliance. Compensating: control-by-control self-mapping is published (ISO/IEC 27001 Annex A in STM-GL-010, SOC 2 TSC in CHK-GL-029, CIS v8 in CHK-GL-030, NIST CSF 2.0 in CHK-GL-031), and every mapping is falsifiable against WPR-GL-001 |
| A&A-05 | Audit management process to support planning, risk analysis, control assessment, remediation and reporting | No | CSP | Not established. Compensating: the Exception & Waiver Register (REG-GL-210) and the Risk Register (REG-GL-202) capture the remediation half of this process today. Target Roadmap iso27001 target |
| A&A-06 | Remediation plans for audit findings, with owners and dates | Yes | CSP | Every finding from any source (VAPT, dependency scan, incident review, restore drill) is recorded with a named owner and a date in REG-GL-204 (vulnerabilities) or REG-GL-202 (risks). Remediation targets are published in WPR-GL-001 Section 8.2 |
CSC responsibilities. A hospital wishing to conduct its own audit of Pensieve Labs may do so under
ADD-GL-001. The audit right, its notice period and its frequency are contractual, not discretionary.
Pensieve Labs also permits customer-initiated penetration testing of the hospital's own tenant under
the conditions in WPR-GL-001 Section 6.5.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| AIS-01 | Application security policy and procedures, reviewed annually | Yes | CSP | The secure SDLC is documented in WPR-GL-001 Section 7 and binding on every change. Reviewed on the cadence in 31 July 2027 |
| AIS-02 | Application security baseline requirements established for each application | Yes | CSP | Baseline: authenticated by default, deny-by-default authorisation, server-side validation, parameterised queries, output encoding, tenant scoping enforced below the application layer. Mapped to OWASP ASVS in CHK-GL-032 |
| AIS-03 | Application security metrics defined, monitored and reported | Yes | CSP | Tracked per release: open findings by severity and age against the targets in WPR-GL-001 Section 8.2; dependency findings by severity; time from merge to production. Summarised in REP-GL-016 |
| AIS-04 | Secure application design and development standards | Yes | CSP | Mandatory peer review on every change; no direct writes to the production branch; infrastructure as code; secrets never in source. WPR-GL-001 Section 7.1 |
| AIS-05 | Automated application security testing in the pipeline | Yes | CSP | SAST, dependency and container-image scanning run on every pull request and block the merge above the configured severity threshold. Summarised publicly in REP-GL-016 |
| AIS-06 | Automated secure deployment; changes tested before production | Yes | CSP | All production deployment is by pipeline from a reviewed commit. Manual deployment to production is not an available path. DM-4: the hospital schedules the application of a release Pensieve Labs has built and signed |
| AIS-07 | Vulnerabilities remediated in line with the risk-based programme | Partial | CSP | Remediation targets are published and tracked (WPR-GL-001 Section 8.2, REG-GL-204). Independent verification of remediation (the re-test) begins with the first VAPT engagement (REP-GL-004) |
CSC responsibilities. Integrations the hospital configures under the BYOK/BYOC model (ADD-GL-007)
call external systems on the hospital's authority. The security of those external systems, and the scope of
the credentials the hospital supplies, are the hospital's; see DIS-GL-024.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| BCR-01 | Business continuity management and operational resilience policy | Yes | CSP | Published in DIS-GL-014 and summarised in WPR-GL-001 Section 11 |
| BCR-02 | Risk assessment and business impact analysis for continuity planning | Partial | CSP | Impact analysis is performed per deployment model and drives the RTO/RPO commitments in SLA-GL-001. A formally documented, dated BIA covering the whole service portfolio is not yet issued. Target Roadmap iso27001 target |
| BCR-03 | Business continuity strategy established | Yes | CSP | Restore-from-backup into a clean project is the primary strategy for DM-1, DM-2 and DM-3. Rationale and topology in DIS-GL-014 |
| BCR-04 | Documented and communicated continuity plans | Yes | CSP | Executable runbooks, not narrative plans: RBK-GL-019 backup and restore, RBK-GL-020 BC/DR invocation, RBK-GL-013 rollback |
| BCR-05 | Continuity plans include impact, RTO/RPO, communication, roles and dependencies | Yes | Shared | RBK-GL-020 names the roles, the escalation path and the customer-communication step. RTO and RPO for a specific deal are Deal RTO hours and Deal RPO minutes on the Order Form |
| BCR-06 | Continuity plans exercised and reviewed at least annually | Yes | CSP | Restore drills are run on a quarterly cadence and published with measured RTO and RPO against commitment: REP-GL-013 and REP-GL-015. DM-4: the hospital must run its own drill; Pensieve Labs cannot exercise hardware it does not control |
| BCR-07 | Establish communication with stakeholders during a disruption | Yes | Shared | Notification path and content are contractual: DPA-GL-001 and DIS-GL-016. Status communication during an outage follows SLA-GL-001 |
| BCR-08 | Backup: periodic, encrypted, access-controlled, tested | Yes | CSP-shared | Backups are encrypted at rest under the same key hierarchy as production (WPR-GL-001 Section 5.5), access-restricted, and restore-tested on the published drill cadence. DM-4: backup custody, media and off-site rotation are the hospital's (ADD-GL-008) |
| BCR-09 | Disaster response plan with recovery of critical services | Yes | CSP | RBK-GL-020, with the invocation criteria and the decision owner named |
| BCR-10 | Disaster response plan exercised annually or on significant change | Partial | CSP | The restore drill exercises the technical recovery path quarterly. A full disaster-declaration exercise including the commercial and communication limbs is run on the tabletop cadence (REP-GL-014) rather than as a separate drill |
| BCR-11 | Equipment redundancy and resilience for critical infrastructure | Inherited | 3rd-party | Compute, storage and database redundancy are properties of the managed Google Cloud services Pensieve runs on, inside Google's own audited scope. DM-4: hardware redundancy is specified in ADD-GL-008 and procured, owned and maintained by the hospital |
The DM-4 statement that must not be softened. Pensieve Labs publishes no RTO and no RPO
commitment for DM-4 (WPR-GL-001 Section 11.2). A vendor offering the same recovery time for hardware it has
never seen as for its own cloud is not telling you the truth.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| CCC-01 | Change management policy and procedures | Yes | CSP | RBK-GL-023 is the operative procedure; every production change is recorded in REG-GL-205 |
| CCC-02 | Quality testing before deployment | Yes | CSP | Automated test suite plus SAST and dependency gates on every pull request; no green pipeline, no deployment |
| CCC-03 | Change management technology enforced for all changes | Yes | CSP | Production is reachable only from the pipeline. There is no manual deployment path to disable |
| CCC-04 | Unauthorised change protection: restrict who may change production | Yes | CSP | Branch protection, mandatory review, and a deploy identity that no human holds interactively. Human access to production data is separately gated (WPR-GL-001 Section 4.5) |
| CCC-05 | Change agreements with customers where a change affects them | Yes | Shared | Material changes are notified under SLA-GL-001; changes to sub-processors under DIS-GL-009; deprecations under POL-GL-064. DM-4: the hospital schedules and authorises every release |
| CCC-06 | Change management baseline established | Yes | CSP | Infrastructure as code is the baseline; drift is detected on plan and reconciled rather than accepted |
| CCC-07 | Detection of unauthorised baseline changes | Partial | CSP | Configuration drift is detected on every apply, and administrative actions are captured in immutable cloud audit logs. Continuous file-integrity monitoring on running workloads is not implemented. Compensating: immutable, short-lived container images; a running instance is replaced, not patched in place |
| CCC-08 | Exception management for changes made outside the process | Yes | CSP | Emergency change is permitted only via the break-glass path in RBK-GL-022, which is time-bounded, second-approver gated, logged immutably and reviewed after the fact. Exceptions are recorded in REG-GL-210 |
| CCC-09 | Change restoration: ability to roll back | Yes | CSP | RBK-GL-013, with the rollback trigger defined before the change begins, not after it fails |
Pensieve Labs's strongest domain, because it is the one where the platform's architecture does the
work. Full technical detail is in WPR-GL-001 Section 5 and DIS-GL-011.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| CEK-01 | Encryption and key management policy and procedures | Yes | CSP | DIS-GL-011 is the source of truth for algorithms, key hierarchy, rotation and custody |
| CEK-02 | Cryptographic, encryption and key management roles defined | Yes | CSP | Key administration is separated from data access. Who may administer a key ring is recorded in REG-GL-208 |
| CEK-03 | Data encrypted at rest and in transit | Yes | CSP-shared | At rest: AES-256 envelope encryption, with customer-managed encryption keys (CMEK) in Cloud KMS above the platform default. In transit: TLS 1.2 or 1.3 only; plaintext HTTP is served solely as a redirect. DM-4: at-rest encryption depends on the hospital's storage configuration, specified in ADD-GL-008 |
| CEK-04 | Encryption algorithms are appropriate and use validated cryptography | Yes | CSP-shared | AES-256-GCM for data-encryption and key-encryption keys; TLS with modern cipher suites only, weak suites disabled. No Pensieve Labs-authored cryptographic primitives exist |
| CEK-05 | Changes to cryptography follow the change management process | Yes | CSP | A cipher-suite or algorithm change is a production change under RBK-GL-023 and appears in REG-GL-205 |
| CEK-06 | Cryptography risk assessed on a defined frequency | Partial | CSP | Transport configuration is re-scored after every load-balancer or CDN change (REP-GL-017). A scheduled cryptographic-agility review, including post-quantum planning, is not yet on a fixed cadence. Target Roadmap iso27001 target |
| CEK-07 | Encryption and key management system inventoried and audited | Yes | CSP | Key rings, keys and their consumers are declared in infrastructure as code and therefore enumerable; they appear in REG-GL-201 |
| CEK-08 | Key management policy covers generation, use, storage and retirement | Yes | CSP | DIS-GL-011. Keys are generated in Cloud KMS and never leave it in plaintext |
| CEK-09 | Cryptographic keys generated, stored and used securely | Yes | CSP-shared | Generation and custody are inside Cloud KMS. Pensieve Labs personnel do not handle raw key material |
| CEK-10 | Key generation follows defined standards | Yes | 3rd-party | Cloud KMS generates 256-bit AES-GCM keys within Google's own audited service |
| CEK-11 | Key purpose is restricted; keys are not shared across purposes | Yes | CSP | Separate keys protect the database, object storage and the secret store. Per-hospital separation is described per model below |
| CEK-12 | Key rotation at defined intervals | Yes | CSP | Automatic rotation on a configured period recorded in DIS-GL-011. DM-3: rotation is controlled by the hospital in the hospital's own KMS |
| CEK-13 | Key revocation and destruction procedures | Yes | CSP | Key destruction is the primary cryptographic-erasure mechanism used at offboarding (RBK-GL-026), evidenced by CRT-GL-011 |
| CEK-14 | Key inventory maintained | Yes | CSP | Held in REG-GL-201 and reconcilable against Cloud KMS at any time |
| CEK-15 | Key compromise and recovery procedures | Partial | CSP | Revocation and re-encryption paths exist and are described in DIS-GL-011. A rehearsed key-compromise recovery drill has not been run. Compensating: the same restore path exercised quarterly in REP-GL-015 covers the recovery half. Target Roadmap bcdr drill target |
| CEK-16 | Keys stored in a secure repository with restricted access | Yes | CSP-shared | Cloud KMS; access governed by IAM and reviewed under REG-GL-208 |
| CEK-17 | Key custodianship: separation between key holder and data holder | Partial | CSP | Enforced technically by CMEK and IAM separation. Full organisational separation of duties is not achievable at Edsol Edtech Pvt. Ltd.'s size and is not claimed (see WPR-GL-001 Section 13). Compensating: second-approver requirement on production access, and immutable logs the accessing engineer cannot alter |
| CEK-18 | Key exchange performed securely | Yes | CSP | No plaintext key exchange occurs. Hospital-supplied credentials under BYOK/BYOC are transferred by the mechanism in RBK-GL-010, never by email or chat |
| CEK-19 | Encryption of data in transit between all system components | Yes | CSP-shared | Internal service-to-service and service-to-managed-service traffic is encrypted. Pensieve Labs operates no plaintext internal transport |
| CEK-20 | Key management system availability and resilience | Inherited | 3rd-party | A property of Cloud KMS in its region. DM-3: of the hospital's KMS. DM-4: of the hospital's chosen key store |
| CEK-21 | Customer key management capability where offered | No | Shared | Pensieve Labs does not offer hospital-held external key management (EKM/HYOK) in DM-1 or DM-2. Compensating: the equivalent outcome is available architecturally. Choose DM-3, where the CMEK lives in the hospital's own Cloud KMS in the hospital's own project and the hospital can revoke it unilaterally. ADD-GL-009 governs it |
What Pensieve Labs can decrypt, stated plainly. In DM-1 and DM-2, Pensieve Labs holds the
keys and can therefore decrypt hospital data; the controls that matter are the access controls and the
audit trail, not a claim of technical impossibility. In DM-3 the hospital can revoke the key.
In DM-4 Pensieve Labs holds nothing. WPR-GL-001 Section 5.4 says this in full.
No control in this domain is Pensieve Labs's. Edsol Edtech Pvt. Ltd. operates no datacentre and
owns no physical facility in which hospital data resides. Answering "Yes" to physical-security questions
about someone else's building is the most common dishonesty in a completed CAIQ, and this document does not
do it.
| ID | Control | Answer | SSRM | Implementation |
|---|---|---|---|---|
| DCS-01 | Off-site equipment disposal policy | Inherited | 3rd-party | Google Cloud media sanitisation within its audited scope. DM-4: the hospital's, under ADD-GL-008 |
| DCS-02 | Off-site transfer authorisation | Inherited | 3rd-party | As above |
| DCS-03 | Secure area policy and procedures | Inherited | 3rd-party | As above |
| DCS-04 | Secure media transportation | Inherited | 3rd-party | Pensieve Labs transports no physical media containing hospital data in any model |
| DCS-05 | Assets classified by criticality and business impact | Yes | CSP | Logical assets are classified in REG-GL-201. Physical assets in scope are Pensieve Labs endpoints only, covered under UEM |
| DCS-06 | Facility and asset cataloguing | Inherited | 3rd-party | Google Cloud region and zone selection is recorded per deal as Deal data region; the facilities themselves are Google's |
| DCS-07 | Controlled access points to secure areas | Inherited | 3rd-party | DM-4: the hospital's server room. ADD-GL-008 specifies the minimum physical control expected and the hospital confirms it in writing |
| DCS-08 | Equipment identification | Inherited | 3rd-party | |
| DCS-09 | Secure area authorisation | Inherited | 3rd-party | |
| DCS-10 | Surveillance system | Inherited | 3rd-party | |
| DCS-11 | Unauthorised access response training | Inherited | 3rd-party | |
| DCS-12 | Cabling security | Inherited | 3rd-party | |
| DCS-13 | Environmental systems: power, temperature, humidity | Inherited | 3rd-party | DM-4: environmental specification is in ADD-GL-008 and is the hospital's obligation. This is one of the reasons DM-4 breaks the 14-day go-live target |
| DCS-14 | Secure utilities | Inherited | 3rd-party | |
| DCS-15 | Equipment location protection against environmental hazards | Inherited | 3rd-party |
What Pensieve Labs is accountable for here. Choosing a provider whose physical controls are
independently audited, recording which region a hospital's data occupies, and telling the hospital the
truth about DM-4. Google Cloud's own certifications cover its facilities; Pensieve Labs does not
inherit those certifications as its own and does not present them as such. See WPR-GL-005 Section 6 and the
precise permitted wording on MeitY empanelment in the phrase table in WPR-GL-005 and in QRE-GL-008.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| DSP-01 | Security and privacy policy and procedures for data | Yes | CSP | DPA-GL-001 is the binding instrument; POL-GL-053 is the public privacy policy; WPR-GL-001 Section 12 is the technical description |
| DSP-02 | Data inventory: all categories of personal and sensitive data | Yes | CSP | Record of Processing Activities REG-GL-206, maintained per deployment model and per integration |
| DSP-03 | Data classification by type, jurisdiction, sensitivity and criticality | Yes | Shared | Classification scheme in REG-GL-206. The hospital determines the clinical sensitivity of its own content; Pensieve Labs classifies the containers |
| DSP-04 | Data flow documentation | Yes | CSP | Data-flow diagrams per deployment model in WPR-GL-001 Section 3, including every boundary at which patient data crosses out of the platform under DIS-GL-024 |
| DSP-05 | Data ownership and stewardship defined | Yes | Shared | The hospital is the Data Fiduciary in all four models; Edsol Edtech Pvt. Ltd. is the Data Processor. DPA-GL-001 clause 2 |
| DSP-06 | Data protection by design and by default | Yes | CSP | Tenant scoping is enforced below the application layer; data minimisation in support access (WPR-GL-001 Section 12.4); no production data on engineer workstations |
| DSP-07 | Data protection by default in system configuration | Yes | CSP | New tenants are provisioned closed: no public buckets, no default external access, deny-by-default authorisation, audit logging on from the first request |
| DSP-08 | Data privacy by design in the SDLC | Partial | CSP | Privacy review is part of design review for features touching patient data, and a DPIA template exists (REP-GL-020). A mandatory, recorded privacy gate on every feature is not yet enforced in the pipeline. Target Roadmap isms policy set target |
| DSP-09 | Data protection impact assessment performed | Yes | Shared | REP-GL-020 provides the template and a completed exemplar. The DPIA is the hospital's obligation as Data Fiduciary; Pensieve Labs supplies the processor-side content |
| DSP-10 | Sensitive data transfer controls | Yes | CSP | Transfers are TLS-protected; export packages are hashed and manifest-verified (DIS-GL-401); cross-border positions are stated in DIS-GL-019 and assessed in REP-GL-021 |
| DSP-11 | Personal data access, correction and erasure honoured | Yes | Shared | Pensieve Labs provides the functions; the hospital, as Data Fiduciary, decides and responds. Assistance obligation is contractual (DPA-GL-001) |
| DSP-12 | Limitation of purpose in personal data processing | Yes | CSP | Processing is limited to documented instructions in DPA-GL-001. Pensieve Labs does not use hospital data to train models or for any secondary purpose. See the AI boundary in WPR-GL-001 Section 7.5 |
| DSP-13 | Personal data sub-processing disclosed and controlled | Yes | CSP | Sub-processor register DIS-GL-009, with a change-notification commitment and an objection right |
| DSP-14 | Disclosure of personal data notification | Yes | CSP | Law-enforcement request handling and customer-notification commitment in POL-GL-067 |
| DSP-15 | Limitation of production data use in non-production environments | Yes | CSP | Production data is not copied to development or test environments. Test data is synthetic. WPR-GL-001 Section 3.7 |
| DSP-16 | Data retention, archiving and deletion policy | Yes | Shared | Retention configured per tenant; deletion process in RBK-GL-026; post-termination position in DIS-GL-406; evidence in CRT-GL-011 |
| DSP-17 | Sensitive data protection: identification and monitoring of movement | Partial | CSP | Egress paths are constrained and logged. Content-inspecting data-loss prevention is not deployed. Compensating: the number of egress paths is small and enumerated (WPR-GL-001 Section 6.2), export is an audited operation, and no bulk export path exists outside the documented one |
| DSP-18 | Disclosure notification to data subjects | No | CSC | Notification of Data Principals is the hospital's obligation under DPDP Rules 2025 Rule 7(1). Pensieve Labs supplies the content within 4 hours of awareness (DIS-GL-016) so the hospital can meet its own clock. Pensieve Labs does not contact patients directly and will not |
| DSP-19 | Data location: customers informed of the geographic location of their data | Yes | CSP | Region is recorded per deal as Deal data region and published in the Data Residency Statement DIS-GL-019. Every model, including DM-4, where the location is the hospital's own premises |
The one answer a reviewer should push on: DSP-17. Pensieve Labs does not run DLP and says so.
Ask what the actual egress paths are, then check the answer against WPR-GL-001 Section 6.2 and the sub-processor
register. That is a better test than a DLP licence.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| GRC-01 | Information governance programme, sponsored by leadership | Partial | CSP | Security decisions are made and owned at director level. Edsol Edtech Pvt. Ltd. is small enough that this is direct rather than delegated. A formally chartered governance programme with recorded terms of reference is not yet issued. Target Roadmap isms policy set target |
| GRC-02 | Risk management programme: identification, assessment, treatment | Yes | CSP | Risk Register REG-GL-202, with owner, inherent and residual scoring, treatment decision and review date on every entry |
| GRC-03 | Organisational policy reviews at least annually | Partial | CSP | Every published artefact carries review_due_on and appears on the staleness dashboard. A single consolidated annual policy-review record does not yet exist; the per-document review dates are the operative control |
| GRC-04 | Policy exception process | Yes | CSP | Exception & Waiver Register REG-GL-210: every exception has an owner, an expiry date and an approver. An exception without an expiry date is not accepted |
| GRC-05 | Information security programme established and maintained | Yes | CSP | Described end to end in WPR-GL-001; control-level status in STM-GL-010 |
| GRC-06 | Governance responsibility assigned to leadership | Yes | CSP | Accountability sits with Director. Named owners per programme are published in WPR-GL-005 Section 5 |
| GRC-07 | Inventory of applicable legal, statutory, regulatory and contractual requirements | No | CSP | No single consolidated compliance obligations register exists. Compensating: obligations are decomposed into per-framework checklists that are individually complete, namely CHK-GL-024 and CHK-GL-026 (India), CHK-GL-033 (GDPR Article 28), REP-GL-021 (EU/EEA transfers). The underlying research is published per jurisdiction. Consolidation target Roadmap iso27001 target |
| GRC-08 | Special-interest group and authority contact maintained | No | CSP | No formal membership of a security special-interest group or CERT community is held. Compensating: a published vulnerability disclosure channel (POL-GL-059, RFC 9116 security.txt) and the CERT-In reporting path documented in CHK-GL-026 |
DIS-GL-020 is the source of truth for this domain.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| HRS-01 | Background verification policy and procedures | Yes | CSP | Identity and employment verification before production access is granted. Scope stated in DIS-GL-020 |
| HRS-02 | Acceptable use of technology policy | Yes | CSP | Written and acknowledged, including the prohibition on copying production data to a local machine |
| HRS-03 | Clean desk policy | Partial | CSP | Edsol Edtech Pvt. Ltd. operates a small, largely digital workplace. Screen-lock and device-encryption requirements are enforced technically; a separately issued clean-desk policy is not |
| HRS-04 | Remote and home working policy | Yes | CSP | Managed devices only; no production access from unmanaged devices; no split tunnelling to production paths |
| HRS-05 | Asset return on termination | Yes | CSP | A checklist item on the offboarding runbook with a named owner and a recorded completion |
| HRS-06 | Employment termination: access revocation | Yes | CSP | Revocation on the last working day, recorded. Verified at the next access review (REG-GL-208) |
| HRS-07 | Employment agreements include security responsibilities | Yes | CSP | Every person with access to hospital data is bound by a written confidentiality obligation surviving the engagement |
| HRS-08 | Roles and responsibilities documented | Yes | CSP | Owner roles are declared in the frontmatter of every artefact in this system and in REG-GL-208 |
| HRS-09 | Non-disclosure agreements in place | Yes | CSP | Employees and contractors alike. Contractor NDAs are on the NDA-GL-003 form |
| HRS-10 | Security awareness training programme | Yes | CSP | At induction and annually, covering phishing, credential handling, healthcare data handling and the incident-reporting duty. Completion recorded in REG-GL-209 |
| HRS-11 | Personal and sensitive data awareness training | Yes | CSP | The healthcare-specific module of the above; recorded separately in REG-GL-209 |
| HRS-12 | Compliance user responsibility: acknowledgement of policies | Yes | CSP | Acknowledgement is recorded in REG-GL-209 and is a precondition to production access |
| HRS-13 | SSRM communicated to personnel | Partial | CSP | The shared-responsibility position is documented per deployment model in WPR-GL-004 and is used in delivery. A dedicated internal training module on SSRM is not separately delivered |
Scale statement, repeated here because it belongs in the answer and not in a footnote.
Edsol Edtech Pvt. Ltd. is a small company. Full separation of duties between development and operations is
not achievable at this size and is not claimed. The compensating controls are mandatory peer review,
the second-approver requirement on production access, and immutable audit logs the accessing engineer
cannot alter. WPR-GL-001 Section 13.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| IAM-01 | Identity and access management policy and procedures | Yes | CSP | RBK-GL-021 provisioning and deprovisioning; WPR-GL-001 Section 4 |
| IAM-02 | Strong password policy and procedures | Yes | Shared | Enforced for Pensieve Labs personnel. Hospital-side password policy is configurable by the hospital; Pensieve Labs sets a secure default and does not permit it to be disabled |
| IAM-03 | Identity inventory: all system and service identities | Yes | CSP | Human and service identities are enumerated in REG-GL-201 and reconciled at each access review |
| IAM-04 | Separation of duties in access design | Partial | CSP | Enforced where role separation exists: deploy identity, key administration, data access and log administration are distinct. Organisational separation of duties is limited by company size and is not claimed. See HRS Section 9 |
| IAM-05 | Least privilege applied | Yes | CSP | Standing access to production data is not granted by default. Access is requested, justified, second-approved, time-bounded and logged (WPR-GL-001 Section 4.5) |
| IAM-06 | User access provisioning process | Yes | Shared | RBK-GL-021. Hospital users are provisioned by the hospital's named administrator |
| IAM-07 | User access changes and revocation | Yes | Shared | Same runbook; verified at review |
| IAM-08 | User access review at planned intervals | Yes | CSP | Quarterly, recorded in REG-GL-208 with the reviewer named. An access review with no recorded reviewer is treated as not performed |
| IAM-09 | Segregation of privileged access roles | Yes | CSP | Privileged roles are distinct identities, not elevated versions of daily-use identities |
| IAM-10 | Management of privileged access roles | Yes | CSP | Time-bounded elevation with a second approver and immutable logging |
| IAM-11 | Customer-controlled credential and access management | Yes | Shared | The hospital administers its own users within the limits recorded on the Order Form; Pensieve Labs does not create hospital user accounts unilaterally |
| IAM-12 | Service-account and API-key management | Yes | CSP | Service identities are declared in infrastructure as code, scoped narrowly, and rotated. Hospital-supplied external credentials are handled under ADD-GL-007 and RBK-GL-010 |
| IAM-13 | Uniquely identifiable users; no shared accounts | Yes | CSP | Shared logins do not exist for Pensieve Labs personnel. Break-glass is an individually attributable path, not a shared account (RBK-GL-022) |
| IAM-14 | Strong authentication: MFA enforced | Yes | CSP | Phishing-resistant authentication for Pensieve Labs administrative access. Hospital-side MFA availability and enforcement are described in WPR-GL-001 Section 4.1 |
| IAM-15 | Passwords managed securely | Yes | CSP | Managed secret store for system secrets; no secrets in source control, tickets, chat or email. A build-time check enforces this |
| IAM-16 | Authorisation mechanisms: deny by default | No | CSP | The control as written asks for a formally documented and periodically re-validated authorisation matrix per system. The technical control is implemented: authorisation is deny-by-default and role-based (WPR-GL-001 Section 4.2). What does not yet exist is the documented, reviewed matrix covering every internal system. Compensating: quarterly access review in REG-GL-208 catches the same drift after the fact. Target Roadmap iso27001 target |
The domain in which an unknown vendor should be strongest, because portability is the hospital's insurance
against Pensieve Labs failing. WPR-GL-400 is the binding commitment.
| ID | Control | Answer | SSRM | Implementation |
|---|---|---|---|---|
| IPY-01 | Interoperability and portability policy and procedures | Yes | CSP | Exit & Data Portability Commitment WPR-GL-400, published before contract rather than produced at termination |
| IPY-02 | Application interface availability: documented, secure APIs | Yes | CSP | Authenticated, documented APIs; integration boundary and BYOK/BYOC model in DIS-GL-024 |
| IPY-03 | Secure interoperability and portability management | Yes | CSP | Export packages are hashed, manifested and independently verifiable by the hospital without Pensieve Labs software; the verification procedure is CHK-GL-023 Part A |
| IPY-04 | Data portability: export in a standard, documented format | Yes | CSP | Format specification DIS-GL-401: open formats, a load guide, DICOM for imaging, FHIR where applicable, and rendered PDFs of clinical encounters. Delivery is evidenced by CRT-GL-010 |
Test this one during evaluation. Ask for an export of a demonstration tenant and try to load it
yourself. It is the cheapest way to falsify a portability claim, and Pensieve Labs invites it.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| IVS-01 | Infrastructure and virtualisation security policy | Yes | CSP | WPR-GL-001 Section 3 and Section 6; infrastructure is declared as code and reviewed as code |
| IVS-02 | Capacity and resource planning | Yes | CSP | Monitored per tenant; load and capacity testing reported in REP-GL-019 |
| IVS-03 | Network security: segmentation and traffic control | Yes | CSP | Documented ingress path with TLS termination and WAF; constrained, enumerated egress; no direct public route to the database or object store (WPR-GL-001 Section 6) |
| IVS-04 | OS hardening and base configuration | Yes | CSP | Minimal, immutable container images from pinned bases, rebuilt and redeployed rather than patched in place |
| IVS-05 | Production and non-production environments separated | Yes | CSP | Separate projects, separate credentials, no production data outside production (WPR-GL-001 Section 3.7) |
| IVS-06 | Segmentation and segregation between tenants | Yes | CSP | DM-1 and DM-3: separate cloud projects, the strongest available boundary. DM-2: logical isolation with row-level security and per-tenant data keys wrapped by a KEK in Cloud KMS. The mechanism, and its limits, are stated in WPR-GL-001 Section 3.4 rather than asserted |
| IVS-07 | Migration to cloud environments performed securely | Yes | CSP | Data migration runbook RBK-GL-008, with reconciliation evidenced by CRT-GL-003 |
| IVS-08 | Network architecture documented and kept current | Yes | CSP | Per-model architecture and data-flow diagrams in WPR-GL-001 Section 3, versioned with the document |
| IVS-09 | Network defence: detection and prevention of anomalous traffic | Partial | CSP-shared | WAF and platform-level denial-of-service protection are in place. Pensieve Labs does not operate a network intrusion-detection system with tuned signatures, and does not claim one. Compensating: a small, enumerated ingress surface; immutable logs; alerting on authentication and authorisation anomalies (WPR-GL-001 Section 9.4) |
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| LOG-01 | Logging and monitoring policy and procedures | Yes | CSP | WPR-GL-001 Section 9; retention position also stated in DIS-GL-011 |
| LOG-02 | Audit logs protected from tampering | Yes | CSP | Written to an immutable regional log bucket with retention lock. An engineer with production access cannot alter the record of that access: this is the control that compensates for limited separation of duties |
| LOG-03 | Security monitoring and alerting | Partial | CSP | Monitoring and alerting operate with an on-call rotation. Pensieve Labs does not operate a 24×7 staffed security operations centre and does not claim one (WPR-GL-001 Section 9.4). Compensating: automated alerting on defined conditions, a published incident-response clock, and the contractual 4-hour notification |
| LOG-04 | Audit log access restricted to authorised personnel | Yes | CSP | Log administration is a distinct role from data access |
| LOG-05 | Audit logs monitored for anomalies | Partial | CSP | Defined alerting conditions are monitored automatically. Behavioural analytics over the full log corpus are not implemented |
| LOG-06 | Clock synchronisation across systems | Yes | CSP-shared | Managed platform time sources; log timestamps are consistent and comparable across services |
| LOG-07 | Logging scope covers security-relevant events | Yes | CSP | Authentication, authorisation decisions, administrative actions, configuration changes, data access to patient records, exports, key operations, and integration calls made on the hospital's authority |
| LOG-08 | Log records include the required fields | Yes | CSP | Actor identity, action, object, timestamp, source, and outcome |
| LOG-09 | Log protection in transit and at rest | Yes | CSP-shared | Encrypted in transit and at rest under the same key hierarchy as production data |
| LOG-10 | Encryption monitoring and reporting | No | CSP | There is no automated control that continuously verifies that every store remains encrypted with the intended key and alerts on deviation. Compensating: encryption is set declaratively in infrastructure as code, and drift is detected on every apply (CCC-07). Target Roadmap iso27001 target |
| LOG-11 | Transaction and business-process logging | Yes | CSP | The clinical and administrative audit trail is a product feature, not only an infrastructure log: who viewed or altered which patient record, and when. WPR-GL-001 Section 7.4 |
| LOG-12 | Access control logs for physical and logical access | Yes | CSP-shared | Logical access logs as above; physical access logs are the cloud provider's, or in DM-4 the hospital's |
| LOG-13 | Failures and anomalies logged and reviewed | Yes | CSP | Error and failure conditions are logged, alerted on and reviewed; incident-linked entries flow to REG-GL-203 |
Retention: 365 days minimum, immutable, and for Indian deployments held in India. The number is chosen
to satisfy the longest of the overlapping obligations rather than the shortest (WPR-GL-001 Section 9.2).
DM-4: log retention depends on the hospital's storage allocation and is specified in ADD-GL-008.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| SEF-01 | Security incident management policy and procedures | Yes | CSP | DIS-GL-016 is the binding commitment; RBK-GL-017 is the executable procedure |
| SEF-02 | Service management policy for incidents | Yes | CSP | Severity definitions, response and restoration targets in SLA-GL-001 |
| SEF-03 | Incident response plans with defined roles and communication | Yes | Shared | RBK-GL-017 names the incident commander role and the customer-communication step. Per-model detection and declaration responsibilities are tabulated in WPR-GL-001 Section 10.4 |
| SEF-04 | Incident response testing at planned intervals | Yes | CSP | Tabletop exercises on a scheduled cadence, published as a two-page summary with measured clock performance (REP-GL-014) |
| SEF-05 | Incident response metrics collected | Partial | CSP | Time to detect, time to notify against the 4-hour commitment, and time to contain are recorded per incident in REG-GL-203. A published trend series does not yet exist because the incident population is small |
| SEF-06 | Event triage and correlation | Yes | CSP | Triage assigns severity at awareness, and the notification clock starts at awareness rather than at triage. The distinction is deliberate and contractual |
| SEF-07 | Security breach notification to regulators and affected parties | Yes | Shared | Pensieve Labs notifies the hospital within 4 hours of awareness, with content sufficient for the hospital to file its own report without a second round trip. The hospital notifies CERT-In and the Data Protection Board; it is the Data Fiduciary. The three clocks are set out in WPR-GL-001 Section 10.1 and CHK-GL-026 |
| SEF-08 | Forensic support for investigation | No | CSP | Edsol Edtech Pvt. Ltd. retains no forensic investigation firm on standby and holds no in-house forensic capability. Compensating: immutable 365-day logs preserved on incident declaration, a documented evidence-preservation step in RBK-GL-017, and a commitment to engage a qualified external firm at Pensieve Labs's cost where an incident warrants it. Retainer decision Roadmap forensics retainer target |
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| STA-01 | SSRM policy and procedures | Yes | CSP | WPR-GL-004 states the split per deployment model; every technical artefact carries an applicability matrix |
| STA-02 | SSRM supply chain: dependencies documented | Yes | CSP | Sub-processor register DIS-GL-009, and the software dependency set as an SBOM in CycloneDX and SPDX per release |
| STA-03 | SSRM guidance published for customers | Yes | CSP | This document, WPR-GL-004, and the per-model responsibility tables throughout WPR-GL-001 |
| STA-04 | SSRM control ownership delineated | Yes | CSP | The SSRM column in this document; contractually in ADD-GL-001 and DPA-GL-001 |
| STA-05 | SSRM documentation review at planned intervals | Yes | CSP | Each artefact carries review_due_on and appears on the staleness dashboard |
| STA-06 | SSRM control implementation verified for supply chain | No | CSP | Pensieve Labs does not independently test its sub-processors' controls. Compensating: sub-processor selection is restricted to providers holding current independent certification, the register names the entity and the processing location so the claim is checkable, and contractual flow-down is required under DPA-GL-001 |
| STA-07 | Supply chain inventory maintained | Yes | CSP | Third-Party Contract Register REG-GL-212 and Sub-processor Register DIS-GL-009 |
| STA-08 | Supply chain risk management: assessment of third parties | Partial | CSP | New sub-processors are assessed against a documented set of criteria before engagement, and the decision is recorded in REG-GL-212. Periodic reassessment of existing sub-processors is not yet on a fixed cadence |
| STA-09 | Third-party agreements include security requirements | Yes | CSP | Required by DPA-GL-001; recorded per contract in REG-GL-212 |
| STA-10 | Supply chain agreement review at planned intervals | Partial | CSP | Reviewed on renewal and on any change of processing. A calendar-driven review independent of renewal is not yet established |
| STA-11 | Internal compliance testing of supply chain controls | No | CSP | Not performed. Compensating: the sub-processor set is deliberately small and enumerable, and every entry in DIS-GL-009 is externally verifiable by the hospital |
| STA-12 | Supply chain service-agreement compliance monitored | Partial | CSP | Availability and incident notifications from sub-processors are monitored operationally. A formal SLA-compliance scorecard per sub-processor does not exist |
| STA-13 | Supply chain governance reviews at planned intervals | No | CSP | No formal governance review forum exists. Compensating: sub-processor changes require customer notification and carry an objection right (DIS-GL-009), which places the governance check with the hospital rather than concealing it. Target Roadmap iso27001 target |
| STA-14 | Supply chain data security assessment | Yes | CSP | Data categories, processing purpose, location and transfer mechanism are recorded per sub-processor in DIS-GL-009 and assessed for EU/EEA transfers in REP-GL-021 |
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| TVM-01 | Threat and vulnerability management policy and procedures | Yes | CSP | WPR-GL-001 Section 8; register REG-GL-204 |
| TVM-02 | Malware protection policy and procedures | Partial | CSP | Endpoint protection on managed devices. Server-side anti-malware is not deployed on the platform, because the workload runs as immutable containers with no interactive shell and no persistent writable filesystem. Uploaded files are scanned. This is a design position, stated rather than hidden |
| TVM-03 | Vulnerability remediation schedule with defined timeframes | Yes | CSP | Critical 72 hours, high 14 days, medium 60 days, low next release cycle. Published in WPR-GL-001 Section 8.2; missed targets are recorded, not reclassified |
| TVM-04 | Detection updates applied promptly | Yes | CSP-shared | Scanner and dependency-advisory data are refreshed continuously by the managed tooling in the pipeline |
| TVM-05 | External library and dependency vulnerabilities managed | Yes | CSP | Dependency scanning on every pull request; SBOM per release in both CycloneDX and SPDX; open-source licence position tracked in REG-GL-213 |
| TVM-06 | Penetration testing performed by independent parties | No | CSP | No independent penetration test has been completed. This is the single most material gap in this assessment. Compensating: automated SAST, DAST and dependency scanning in the pipeline (REP-GL-016); a published vulnerability disclosure policy with response commitments (POL-GL-059); and a permissive customer-testing policy allowing the hospital to test its own tenant. A CERT-In empanelled VAPT is scheduled for Roadmap vapt target; the attestation letter will publish as REP-GL-001 and the Safe-to-Host certificate as REP-GL-004 |
| TVM-07 | Vulnerability identification through automated scanning | Yes | CSP | Continuous in the pipeline and against running environments |
| TVM-08 | Vulnerability prioritisation by risk | Yes | CSP | CVSS v3.1 base score adjusted for exploitability in Pensieve's actual configuration, with the reasoning recorded rather than assumed |
| TVM-09 | Vulnerability management reporting to stakeholders | Partial | CSP | Published quarterly in summary as REP-GL-016. Per-hospital reporting is provided on request under ADD-GL-001 rather than by default |
| TVM-10 | Vulnerability management metrics established | No | CSP | Counts and ages are tracked in REG-GL-204, but a defined metric set with thresholds and a reporting cadence is not established. Compensating: the remediation targets themselves function as the threshold, and breaches of them are visible in the register. Target Roadmap iso27001 target |
Scope note: this domain concerns Pensieve Labs's own endpoints. Hospital endpoints are the
hospital's and are addressed in CHK-GL-025.
| ID | Control | Answer | SSRM | Implementation / compensating control |
|---|---|---|---|---|
| UEM-01 | Endpoint management policy and procedures | Yes | CSP | DIS-GL-020; managed devices only for production access |
| UEM-02 | Application and service approval on endpoints | Partial | CSP | Policy-based rather than technically enforced by allow-listing on every device |
| UEM-03 | Compatibility of endpoints with cloud services | Yes | CSP | A managed, current, supported operating system is a precondition of production access |
| UEM-04 | Endpoint inventory maintained | Yes | CSP | Held in REG-GL-201; reconciled at each access review |
| UEM-05 | Endpoint management enforced for all endpoints with access | Yes | CSP | Personal devices cannot reach production. This is enforced, not requested |
| UEM-06 | Automatic lock screen | Yes | CSP | Enforced by device policy |
| UEM-07 | Operating systems and software patched | Yes | CSP | Automatic updates enforced by device policy |
| UEM-08 | Storage encryption on endpoints | Yes | CSP | Full-disk encryption enforced on every managed device |
| UEM-09 | Anti-malware on endpoints | Yes | CSP | Endpoint protection deployed and centrally reported |
| UEM-10 | Software firewall on endpoints | Yes | CSP | Enabled by device policy |
| UEM-11 | Data loss prevention on endpoints | No | CSP | Endpoint DLP is not deployed. Compensating: production data is not permitted on a local machine at all (WPR-GL-001 Section 13), support access is minimised by design (Section 12.4), and there is no bulk export path outside the audited one |
| UEM-12 | Remote geolocation of endpoints | No | CSP | Not implemented, as a deliberate privacy position on staff devices. Compensating: remote wipe (UEM-13) and full-disk encryption make a lost device a low-consequence event |
| UEM-13 | Remote wipe capability | Yes | CSP | Available and exercised as part of offboarding where a device cannot be returned in person |
| UEM-14 | Third-party endpoint security posture verification | No | CSP | Contractor devices are held to the same written requirements as employee devices, but their posture is not independently verified by tooling in every case. Compensating: contractors are named in the access register (REG-GL-208), hold time-bounded access, and are subject to the same second-approver control on production. Target Roadmap isms policy set target |
| Answer | Count | Share |
|---|---|---|
| Yes | 126 | 64% |
| Partial | 30 | 15% |
| No | 24 | 12% |
| Inherited / CSC / N/A | 17 | 9% |
| Total | 197 | 100% |
What the shape means. The Yes answers cluster in the domains where the platform's architecture does the work: cryptography, change control, identity, portability, logging. The No answers cluster in two places: independent assurance (A&A, and TVM-06), which is a question of money and elapsed time rather than engineering; and programme formalism (consolidated obligations registers, governance forums, metric frameworks), which is what an ISO 27001 implementation produces.
That is the honest profile of a small engineering-led company that has built the controls before it has bought the certificates. A reviewer should weigh it accordingly, and should test it, using Section 20.
The 24 controls answered No, each with its compensating control and target. A reviewer who wants only the gaps can read this table alone.
| ID | Gap | Compensating control | Target |
|---|---|---|---|
| A&A-02 | No independent audit | CERT-In empanelled VAPT engaged; ISO 27001 programme running | Roadmap iso27001 target |
| A&A-04 | No third-party verification of compliance | Published, falsifiable self-mappings: STM-GL-010, CHK-GL-029 to CHK-GL-032 |
Roadmap iso27001 target |
| A&A-05 | No audit management process | Risk and exception registers carry the remediation function | Roadmap iso27001 target |
| CEK-21 | No customer-held external key management in DM-1/DM-2 |
DM-3 gives the hospital its own KMS and a unilateral revocation |
Architectural, available today |
| DSP-18 | Pensieve Labs does not notify Data Principals |
The hospital notifies; Pensieve Labs supplies content within 4 hours |
By design, will not change |
| GRC-07 | No consolidated compliance obligations register | Complete per-framework checklists and per-jurisdiction research | Roadmap iso27001 target |
| GRC-08 | No security special-interest group membership | Published disclosure channel; documented CERT-In reporting path | Roadmap isms policy set target |
| IAM-16 | No documented authorisation matrix per internal system | Deny-by-default implemented technically; quarterly access review | Roadmap iso27001 target |
| LOG-10 | No continuous encryption-state monitoring | Declarative encryption in code; drift detected on apply | Roadmap iso27001 target |
| SEF-08 | No forensic retainer or in-house capability | Immutable 365-day logs preserved on declaration; external firm engaged at Pensieve Labs's cost |
Roadmap forensics retainer target |
| STA-06 | Sub-processor controls not independently tested | Certified providers only; register is externally checkable | Roadmap iso27001 target |
| STA-11 | No internal compliance testing of the supply chain | Small, enumerable sub-processor set | Roadmap iso27001 target |
| STA-13 | No supply-chain governance review forum | Change notification with a customer objection right | Roadmap iso27001 target |
| TVM-06 | No independent penetration test completed | Pipeline SAST/DAST/dependency scanning; VDP with response commitments; customer testing permitted | Roadmap vapt target |
| TVM-10 | No formal vulnerability metric set | Published remediation targets act as thresholds; breaches visible in REG-GL-204 |
Roadmap iso27001 target |
| UEM-11 | No endpoint DLP | Production data not permitted on local machines at all | Roadmap isms policy set target |
| UEM-12 | No endpoint geolocation | Deliberate privacy position; remote wipe and full-disk encryption | Will not change |
| UEM-14 | Contractor endpoint posture not tool-verified | Named, time-bounded access; second-approver control on production | Roadmap isms policy set target |
Six further No answers are recorded inline against DCS-adjacent and HRS-adjacent controls where the substantive answer is that the control belongs to the hospital or to the cloud provider under the applicable deployment model; those rows are not repeated here because the "gap" is a boundary, not a deficiency.
Nothing above requires you to trust Edsol Edtech Pvt. Ltd.. Six checks, none of which need
Pensieve Labs's cooperation, and all of which can be done during evaluation:
https://trust.pensievelabs.org. Compare with REP-GL-017./.well-known/security.txt and time the
acknowledgement against the published 3-business-day commitment.DIS-GL-009 is a real company; check that each
one does what is claimed and is located where it is claimed.DIS-GL-401. IPY-04 either
survives that or it does not.DPA-GL-001, SLA-GL-001 and ADD-GL-001 are published.
Check that the 4-hour notification in SEF-07 actually appears in them.Pensieve Labs to test its own answers in front of you. Any row in this document can be
demonstrated on a screen share; ask for the three you care about most.| If you want | Read |
|---|---|
| A shorter version for a first-pass screen | QRE-GL-006 CAIQ-Lite |
| Answers to your own bespoke questionnaire | QRE-GL-008 Master Answer Sheet |
| The ISO/IEC 27001 Annex A position | STM-GL-010 Statement of Applicability |
| When certification is expected | STM-GL-011, STM-GL-012 |
What Pensieve Labs does not have at all |
WPR-GL-005 Section 6 |
| The technical detail behind any "Yes" | WPR-GL-001 |
I confirm that the answers in this document are, to the best of my knowledge and belief, a true and
complete statement of Edsol Edtech Pvt. Ltd.'s controls as at 31 July 2026; that no answer
has been recorded as implemented where it is not; and that this document has not been reviewed,
validated or attested by any independent party.
| Signature | ______________________________ |
| Name | [TO BE SUPPLIED] |
| Designation | Director |
| For | Edsol Edtech Pvt. Ltd. |
| Date | 31 July 2026 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 31 July 2026 |
Security | First issue. All 197 CCM v4 controls answered per deployment model. |
Attribution. The Cloud Controls Matrix and the Consensus Assessments Initiative Questionnaire are
works of the Cloud Security Alliance. This document is Edsol Edtech Pvt. Ltd.'s response to that question
set; it is not a CSA publication and carries no CSA endorsement. Edsol Edtech Pvt. Ltd. is not certified
under CSA STAR Level 2.