ISO 27701 Clause 6.1: Actions to Address Risks and Opportunities

Quick Reference (60 Seconds)

If you only read one thing: Clause 6.1 is where the PIMS stops being a policy document and becomes a risk-managed system. A 6.1-conformant PIMS is one in which the organisation has a documented privacy-risk methodology that measures impact on PII principals first and on the organisation second, has identified the privacy risks for every in-scope processing activity, has run a DPIA / DPIP wherever a trigger fires (DPDP section 10, GDPR Article 35, ISO/IEC 29134:2017), has selected a treatment option for every material risk, has produced a PIMS Statement of Applicability that cross-walks every Annex A.1 / A.2 / A.3 control to a current-state implementation with a defensible justification, and has a risk-acceptance record for every risk above the threshold. Not a risk register copied from a template with every risk scored \"medium\" and every control marked \"applicable\". The certification auditor will trace risks forward into the SoA, the policy, the ROPA, the awareness programme and the breach playbook, and the Data Protection Board of India will, after a principal complaint or a breach, ask which risks were identified, which DPIAs were done, and which controls were in place. Get 6.1 wrong, a thin reskin of the infosec risk register, no DPIA, a SoA copied from a template, no principal-impact axis, no risk-acceptance record, and however strong the rest of the PIMS is, the certificate will be at risk because every downstream control is unjustified. Get it right, and every other clause becomes easier to evidence because the planning architecture is sound.

What the Standard Actually Requires

The paraphrased requirement

ISO/IEC 27701:2025 Clause 6.1 asks organizations to plan how to handle privacy risks and opportunities, including privacy risk assessment and treatment. Three sub-clauses do the work: 6.1.1 (General), 6.1.2 (Privacy risk assessment) and 6.1.3 (Privacy risk treatment). Each carries a distinct load.

Sub-clause 6.1.1, General (the planning cycle)

Sub-clause 6.1.1 is the planning-cycle anchor. The organisation is asked to plan the actions that arise from the issues it identified in Clause 4.1 (context), the requirements it determined in Clause 4.2 (interested parties) and the scope it set in Clause 4.3, and to do so in a way that gives reasonable assurance the PIMS can achieve its intended outcome, prevent or reduce undesired effects, and achieve continual improvement. Three building blocks do the work.

First, the organisation must integrate the planning actions into the PIMS processes. Planning is not a side activity; it shapes how the PIMS processes operate day to day. The Clause 8 operational processes (the ROPA, the consent management, the rights handling, the processor management, the cross-border transfer mechanism, the breach playbook) inherit their risk-based design from 6.1.

Second, the organisation must assure itself that the PIMS can achieve its intended outcome. The intended outcome, set out in Clause 4.4, is a PIMS that supports the privacy policy (5.2), meets the privacy objectives (6.2), conforms to the standard's requirements, and continually improves. The 6.1.1 plan must demonstrate, on the evidence, that the controls selected are sufficient to that outcome.

Third, the organisation must address both risks and opportunities. Risks are the undesired effects, privacy harm to PII principals, non-compliance with requirements, regulatory exposure, contractual breach. Opportunities are the positive effects, privacy-by-design wins that reduce the data footprint, consent-quality improvements that increase trust, processor consolidation that reduces the attack surface, automation that reduces human error. Most PIMS programmes over-index on risks and miss the opportunity axis; the 2025 edition explicitly asks for both.

Sub-clause 6.1.2, Privacy risk assessment (the methodology)

Sub-clause 6.1.2 is the privacy-risk-assessment methodology. The organisation is asked to carry out a privacy risk assessment that is documented, defensible, and integrated (or at least reconciled) with the infosec risk assessment. Four moves do the work.

First, the organisation must identify the privacy risks. Privacy risks arise from the processing activities the organisation conducts (the ROPA-type records under Clause 8), the requirements it must satisfy (Clause 4.2), the issues it identified in context (Clause 4.1), and the threat landscape (the actors, the vulnerabilities, the events that could materialise a harm). The identification method must be documented, a free-form brainstorm does not satisfy 6.1.2.

Second, the organisation must analyse the privacy risks. The analysis combines likelihood (the probability that the threat materialises, given the controls in place) with impact, and the load-bearing 2025-edition discipline is that the impact analysis must consider, separately, the impact on PII principals (the individuals whose data is processed) and the impact on the organisation. The principal-impact axis is what differentiates a privacy risk assessment from an infosec risk assessment: a breach of 50,000 records is a privacy risk because of the 50,000 individuals whose autonomy, dignity, financial standing, safety or rights may be affected, not because of the regulatory fine the organisation may pay.

Third, the organisation must evaluate the privacy risks, compare the analysed risk against documented risk criteria and produce a risk rating (typically inherent risk on one axis, residual risk on another). The risk criteria must be documented; an undocumented \"gut feel\" rating does not satisfy 6.1.2.

Fourth, the organisation must maintain the privacy risk assessment as Documented Information, the methodology, the register, the DPIAs, the criteria, the analysis. The documentation must be current at the audit date and reviewed on the cadence the procedure prescribes (annual plus event-trigger).

Sub-clause 6.1.3, Privacy risk treatment (the decisions)

Sub-clause 6.1.3 is the privacy-risk-treatment decision cycle. The organisation is asked to select treatment options for every material risk, implement the treatment, produce a Statement of Applicability and record the risk-treatment results. Five moves do the work.

First, the organisation must select a treatment option for each material risk. The four options inherited from ISO 31000 / ISO/IEC 27005 are: modify (apply controls to reduce the likelihood or the impact, the canonical option for most privacy risks), retain (accept the residual risk, requires a documented risk-acceptance record), avoid (terminate the processing activity that generates the risk, the option for risks that exceed the risk appetite and cannot be modified), and share (transfer part of the risk, typically through insurance or through contractual allocation to a processor). The 2025 edition expects the treatment-option selection to be documented per risk, not as a blanket policy choice.

Second, the organisation must determine the controls that implement the modify option. The control menu is Annex A of the standard: A.1 (PII controller controls, 31 in the consensus count), A.2 (PII processor controls, 18), A.3 (information security controls applicable to controllers and processors, approximately 29, aligned to ISO/IEC 27002:2022). The control selection must be defensible, every applicable control traces to a risk or a requirement; every excluded control has a documented justification.

Third, the organisation must produce a PIMS Statement of Applicability. The SoA is the load-bearing 6.1.3 artefact. It cross-walks every Annex A control to (a) its applicability status (applicable / not applicable), (b) the justification (the risk or the requirement it treats), (c) the implementation state, current-state, not future-state, and (d) the evidence reference. The current-state discipline is the most-violated SoA rule in certification audits: a SoA that documents a control as applicable when the implementation is planned but not yet in operation is a nonconformity. The SoA must also document the exclusions with reasoning, a control marked \"not applicable\" on a hypothetical future relationship (\"we may have a joint controller next year\") is the canonical 6.1.3 audit failure flagged in tier-1 practitioner commentary.

Fourth, the organisation must implement the treatment, the controls selected in the SoA must actually be put into operation. The implementation evidence lives in the Clause 8 operational processes (ROPA, consent, rights, processor management, transfer, breach) and in the Annex A.3 security controls.

Fifth, the organisation must record the risk-treatment results, the residual risk after treatment, the risk-owner sign-off, the risk-acceptance record for risks above the threshold, the comparison against the risk criteria. The risk-treatment record is the audit-evidence artefact that proves the cycle ran end-to-end.

The principal-impact axis, the load-bearing 2025 discipline

The single most important conceptual point in Clause 6.1 is that privacy risk is measured primarily by impact on PII principals. This is the privacy-specific load that distinguishes the PIMS risk assessment from the ISMS risk assessment.

The infosec risk tradition (ISO/IEC 27001:2022 Clause 6.1.2, ISO/IEC 27005:2022, NIST SP 800-30) measures risk in terms of impact on the organisation, the confidentiality, integrity and availability of the organisation's information assets, with business-impact ratings (financial loss, operational disruption, regulatory penalty, reputational damage). The privacy risk tradition (GDPR Article 35, ISO/IEC 29134:2017, ISO/IEC 27557, the WP248 DPIA criteria) measures risk in terms of impact on the individual, the PII principal's autonomy, dignity, financial standing, safety, non-discrimination, and ability to exercise their rights. The two traditions overlap on the technical-threat axis (a ransomware attack is both an infosec risk and a privacy risk) but diverge on the impact axis (the infosec impact is operational disruption; the privacy impact is the principal's exposure to identity theft, fraud, distress, or loss of control).

The 2025 edition inherits the privacy-impact tradition: the 6.1.2 risk analysis must consider the principal impact as the primary axis. The 6.1 audit will sample a processing activity and ask \"what is the principal-impact rating?\"; if the answer is \"we rate it medium because the regulatory fine is bounded\", the PIMS has a 6.1 finding because the principal-impact axis is missing.

The Singahi principal-impact rating scale (toolkit doc 02 annex) provides a structured way to capture the impact on the principal across six dimensions: autonomy (loss of control over personal data), dignity (distress, embarrassment, reputational harm), financial standing (fraud, identity theft, financial loss), safety (physical or psychological harm, particularly for vulnerable principals), non-discrimination (unfair or discriminatory outcomes, particularly for AI-driven processing), and rights (the ability to exercise access, correction, erasure, objection).

The DPIA / DPIP trigger test, when a deeper analysis is required

The privacy risk assessment produces a register of risks with ratings. For the subset of processing activities that trigger a deeper analysis, the organisation must run a Data Protection Impact Assessment (DPIA, in GDPR language) or Data Protection Impact Procedure (DPIP, in the DPDP section 10 language, the Act uses \"DPIP\" in the SDF context). The trigger test draws from three sources.

First, DPDP Act 2023 section 10 (Significant Data Fiduciary obligations). A Data Fiduciary designated as Significant must perform a DPIP for each new processing activity, a periodic independent data audit, and an algorithmic-AI fairness review where AI/statistical inference is involved. For an Indian SDF, the DPIP is mandatory; the question is not whether to do it but how to scope it. The DPIP obligation is the densest overlap with ISO/IEC 27701:2025 clause 6.1.2 / 8.2 / Annex A.1.2.5.

Second, GDPR Article 35 (Data Protection Impact Assessment). Where the organisation processes EU/EEA personal data meeting the Article 35(1) criteria, \"likely to result in a high risk to the rights and freedoms of natural persons\", a DPIA is mandatory. The Article 29 Working Party WP248 rev.01 lists nine criteria, any two of which trigger a DPIA: evaluation or scoring (including profiling and prediction); automated decision-making with legal or similar significant effect; systematic monitoring; sensitive data or data of a highly personal nature (special categories under Article 9, financial data, location data, communication data); data processed on a large scale; matching or combining datasets (e.g., from two distinct processing operations); data concerning vulnerable data subjects (children, employees, mentally ill persons, asylum seekers); innovative use or applying new technological or organisational solutions (e.g., fingerprint, face-recognition, AI-driven profiling); and data transfer outside the EU where no adequacy decision and no appropriate safeguards. The CNIL maintains a public list of processing operations that require a DPIA; the EDPB consolidates the EU-wide position.

Third, ISO/IEC 29134:2017 (Guidelines for privacy impact assessment). The international standard for the PIA / DPIA methodology. The 2025 edition's Annex A.1.2.5 (privacy impact assessment) cross-references it; the deeper 6.1.2 analysis is expected to follow the 29134 structure: a systematic description of the processing, the context, the necessity and proportionality test, the principal-impact analysis, the risk evaluation, the treatment, the residual risk, and the consultation record.

The Singahi DPIA / DPIP trigger test (toolkit doc 02 procedure, annex B) operationalises all three sources in a single decision tree. For most Indian growing companies the DPIA register covers 5 to 30 processing activities; for SDFs and large enterprises, 50 to 500.

The integrated-versus-parallel decision, the most-flagged NC zone

The relationship between the privacy risk assessment and the infosec risk assessment is the single most-flagged certification nonconformity zone in tier-1 practitioner commentary. Three patterns dominate: Pattern A (integrated-with-distinction), a single register with both the infosec and the privacy (principal) impact axes, a single SoA covering both control surfaces (ISO/IEC 27002:2022 and 27701 Annex A); the recommended default for most Indian growing companies. Pattern B (parallel), two registers, two methodologies, two SoAs; defensible where the two functions sit in different teams but operationally heavier; the risk is non-reconciliation where the two registers and SoAs disagree on the same processing activity. Pattern C (reskin), the infosec register re-labelled \"privacy\"; the principal-impact axis missing; the DPIA triggers not tested; the single most common 6.1 finding in the Indian growing-company segment. The 2025 edition expects an integrated-with-distinction posture; the Singahi recommended default is Pattern A (Move 1 in Section 7).

What the standard does NOT require (the demarcation)

• 6.1 does not require quantitative risk analysis. A qualitative likelihood × impact matrix with documented criteria is sufficient. Quantitative methods (FAIR, Monte Carlo) are useful for mature programmes but not required.
• 6.1 does not require a specific risk-register tool. A spreadsheet is acceptable for the first cycle; a GRC platform is a maturity upgrade.
• 6.1 does not require a DPIA for every processing activity. The DPIA is required where a trigger fires (DPDP section 10, GDPR Article 35, ISO/IEC 29134). For low-risk processing, the standard assessment suffices.
• 6.1 does not require zero residual risk. The discipline is to identify, analyse, evaluate, treat, and document, including risk-acceptance above the threshold.
• 6.1 does not require the privacy risk assessment to be a standalone methodology. The integrated-with-distinction pattern is acceptable and recommended.
• 6.1 does not require the SoA to be a public document. The SoA is internal Documented Information; a summary may appear in the transparency report.
• 6.1 does not require the risk owner to be the DPO. Risk ownership follows the processing-activity ownership, the business-process owner is the canonical risk owner.
• 6.1 does not require quarterly review. Annual review at the management review is the baseline; event-trigger review (new processing activity, new sub-processor, new jurisdiction, new regulation, post-incident) is the discipline.

The companion guidance, Annex B is normative in 2025

In 27701:2019 the implementation guidance lived in informative Annex F. In 27701:2025 the guidance lives in Annex B (Implementation Guidance for PII Controllers and Processors), and Annex B is normative. For Clause 6.1 specifically, the Annex B guidance (numbered to mirror the clause) explains how the risk methodology should integrate with the infosec methodology, how the principal-impact axis should be rated, and how the DPIA trigger test should be structured. Auditors will test against Annex B, not just against the clause text.

Five external anchors are most relevant for Clause 6.1.

• ISO/IEC 27001:2022 Clause 6.1 (Actions to address risks and opportunities) is structurally identical on the infosec side. The integrated-with-distinction posture uses the shared structure.
• ISO/IEC 27005:2022 (Information security risk management) is the methodological reference for the infosec risk-assessment tradition; the privacy risk methodology inherits the ISO 31000 vocabulary (likelihood, impact, risk criteria, treatment options).
• ISO/IEC 29134:2017 (Guidelines for privacy impact assessment) is the methodological reference for the DPIA tradition; the deeper 6.1.2 analysis is expected to follow the 29134 structure.
• ISO/IEC 27557 (Impact assessment) is the impact-assessment criteria reference cited by tier-1 practitioner commentary as the impact-rating companion to 29134.
• GDPR Article 35 (DPIA), Article 36 (prior consultation), Article 5(2) (accountability), Article 24 (controller responsibility), Article 32 (security) are the external anchors for the EU-relevant processing. The Article 29 WP248 rev.01 nine-criteria DPIA-trigger list is the operational expression of Article 35(1).
• NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), the Identify-P function (data mapping, business environment, risk assessment, data lifecycle) is the US-flavoured structural analogue of the 6.1.2 methodology.

What auditors actually check

The certification auditor's Clause 6.1 examination has seven predictable moves.

First, the auditor opens the Privacy Risk Assessment Procedure. Is there one? Is it dated, version-controlled, signed by top management or the DPO with sponsor authority? Does it document the methodology (identification, analysis, evaluation, treatment, criteria, cadence)? If any of these fails, minor nonconformity. If the document does not exist, major nonconformity.

Second, the auditor tests the principal-impact axis. The auditor picks a sample processing activity and asks \"what is the principal-impact rating?\". If the answer references only the regulatory fine or the operational disruption, the principal-impact axis is missing, major nonconformity.

Third, the auditor tests the integration with the infosec risk assessment. Is the relationship documented (integrated / parallel / reskin)? If parallel, is there a reconciliation? If reskin, the principal-impact axis is missing.

Fourth, the auditor opens the DPIA / DPIP register. Is there a trigger test? Has a DPIA been done for every triggered processing activity? Does the DPIA follow the 29134 / Article 35(7) structure (systematic description, necessity and proportionality, principal-impact, mitigations, residual risk, consultation record)? For Indian SDFs, is the DPIP done per section 10?

Fifth, the auditor opens the PIMS Statement of Applicability. Does it cover every Annex A.1 / A.2 / A.3 control? Is each applicable control justified (the risk or requirement it treats)? Is each non-applicable control justified (the exclusion reasoning)? Does the implementation state reflect current-state (not future-state)? Are there controls marked applicable on a hypothetical future relationship?

Sixth, the auditor tests the risk-treatment record. Is there a treatment plan per material risk? Is there a residual-risk rating? Is there a risk-owner sign-off? Is there a risk-acceptance record for risks above the threshold?

Seventh, the auditor checks the review trail. When was the register last reviewed? Was it at the management review (Clause 9.3)? Have event-trigger reviews happened (a new processing activity since the last review should have produced a risk-assessment update; a post-incident should have produced a re-assessment)? Is there a change-monitoring log?

Why This Control Matters

The risk register as the foundation of every other clause

Every other clause and annex of ISO/IEC 27701:2025 inherits its design rationale from Clause 6.1. The policy (5.2) commits to risk-based privacy; the objectives (6.2) are calibrated to the residual-risk trajectory; the roles (5.3) include the risk owners; the competence (7.2) covers the risk methodology; the awareness (7.3) trains staff on the material risks; the communication (7.4) reports on the risk posture; the operational processes (Clause 8) implement the treatment plan; the DPIA programme (Annex A.1.2.5) operationalises the trigger test; the Annex A.1 / A.2 / A.3 controls are selected by the SoA; the breach playbook (Clause 8 and Annex A.3) is designed around the residual-risk trajectory; the internal audit (9.2) and management review (9.3) test whether the methodology is sound and the controls are effective; the nonconformity and corrective action (10.2) responds to risk realisations; the continual improvement (10.1) sharpens the methodology. Without 6.1, the rest of the PIMS is unmoored.

This is not a stylistic observation. It is the operational reality the certification auditor and the Data Protection Board of India converge on. A PIMS built on a thin reskin of the infosec risk register is, in auditor language, a \"system without risk literacy\", a structural finding that cascades into every other clause because the planning foundation is unsound. A PIMS built on a defensible risk methodology is defensible end-to-end.

The Indian regulatory weight behind 6.1

In India, Clause 6.1 has a regulatory weight that goes beyond the ISO standard itself. The DPDP Act 2023 (Act 22 of 2023, enacted 11 August 2023) and the DPDP Rules 2025 (notified 13 November 2025) make the privacy risk assessment and the DPIA / DPIP statutory necessities, because the obligations the Act imposes are calibrated to the organisation's role (Data Fiduciary vs Data Processor), its designation (Significant Data Fiduciary vs not), and the sectoral overlays (RBI, SEBI, IRDAI) it carries.

The most load-bearing 6.1-relevant DPDP provision is section 10 (Significant Data Fiduciary). A Data Fiduciary designated as Significant must perform a DPIP (Data Protection Impact Procedure, the Act's term) for each new processing activity, a periodic independent data audit by a Board-recognised auditor, and an algorithmic-AI fairness review where AI / statistical inference is involved. The DPIP obligation maps directly to Clause 6.1.2 / 8.2 and Annex A.1.2.5. An Indian SDF implementing ISO/IEC 27701:2025 satisfies most of section 10 with minimal additional work, the PIMS methodology, the DPIA register, the SoA and the risk-treatment record are the artefacts the SDF obligations expect.

The penalty exposure underscores the weight. Section 33 + the Schedule set the maxima: up to 250 crore rupees for section 8(5) failure (reasonable security safeguards), up to 200 crore for section 8(6) failure (breach notification), up to 200 crore for section 9 failure (children's data), up to 150 crore for section 10 failure (SDF obligations, including the DPIP). The risk register must surface these exposures as candidate risks; the treatment plan must apply the controls that mitigate them; the SoA must cross-walk the controls to the section-by-section obligations.

The lineage is the wedge. K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (judgment delivered 24 August 2017 by a nine-judge Bench of the Supreme Court) declared the right to privacy, including informational privacy, a fundamental right under Articles 14, 19 and 21 of the Constitution. The Aadhaar judgment, Justice K.S. Puttaswamy (Retd.) v. Union of India, (2019) 1 SCC 1 (26 September 2018, five-judge Bench) set the proportionality test that the DPDP exemptions must meet. After multiple draft Bills (2019, 2022, 2023), the DPDP Act was enacted on 11 August 2023. The DPDP Rules 2025 were notified on 13 November 2025 with phased commencement. ISO/IEC 27701:2025 was published on 14 October 2025, twelve days before the DPDP Rules were notified. The two instruments were, in effect, made for each other; the risk register is where the legal landscape enters the PIMS.

The dual-clock pattern is the uniquely Indian 6.1-relevant artefact. A single personal-data-breach event triggers two parallel reporting clocks under two parallel regimes: the CERT-In 6-hour clock (CERT-In Directions 20(3)/2022-CERT-In of 28 April 2022, the ICT-incident angle) and the DPDP 72-hour clock (DPDP Act section 8(6) read with DPDP Rules 2025 Rule 7, the personal-data angle). For BFSI and listed entities, a third clock applies (RBI six hours; SEBI 6 hours; IRDAI 24 to 72 hours). The breach playbook, the SoA and the risk-treatment plan must reflect the dual-clock reality.

The cost of non-compliance

The cost of a Clause 6.1 failure breaks down into four bands.

Direct DPDP penalty exposure for an organisation whose risk register missed a material risk (e.g., failed to identify the section 9 children's-data regime as a risk for a K-12 platform, failed to identify the section 16 cross-border negative list as a risk for an overseas analytics flow, failed to run a DPIA where Article 35 triggered for a profiling engine) can run to the Schedule maxima, up to 250 crore rupees for section 8(5), 200 crore for sections 8(6) and 9; 150 crore for section 10.

Indirect regulatory consequences are larger and slower. A risk-register failure that produces an incorrect SoA, an incorrect DPIA conclusion, or an incorrect breach playbook cascades through every other clause and amplifies the cost of every other nonconformity.

Commercial cost is significant. The Indian privacy incidents most cited in board rooms, Juspay (approximately 35 million records in 2021, publicly acknowledged), BigBasket (approximately 20 million records alleged in 2020), Air India / SITA (approximately 4.5 million customers affected by the SITA breach disclosed in 2021), MobiKwik (contested allegations, denied by the company), all carried post-incident examinations that tested whether the organisation had identified the risk (the threat surface, the principal-impact, the trigger event), whether a DPIA had been done, and whether the controls in the SoA were actually in operation. A risk register that does not anticipate the plausible incident scenarios amplifies the commercial cost.

Certification cost is the most immediate. Recoverable; entirely avoidable.

Scope and Applicability

By organisation size

Growing companies (50 to 250 staff). A compact risk-and-treatment artefact: a single Privacy Risk Assessment Procedure of 15 to 25 pages, a risk register of 30 to 80 entries, a DPIA / DPIP register covering 3 to 10 processing activities, a SoA covering all 78 Annex A controls with applicability justification, a risk-acceptance log of 2 to 10 entries. The first cycle is deliverable in 6 to 12 weeks of internal effort plus external advisory.

Mid-market (250 to 2,000 staff). A more granular artefact: a Procedure of 25 to 40 pages, a register of 80 to 250 entries, a DPIA register covering 10 to 30 processing activities, a SoA with detailed current-state evidence per applicable control, an integrated-with-distinction posture with the ISMS risk register. The first cycle typically takes 12 to 20 weeks and requires board-cycle alignment for the risk-acceptance decisions above the threshold.

Multi-entity enterprise (2,000+ staff or multi-jurisdiction). A layered risk architecture: group methodology plus entity-level registers plus jurisdiction-specific DPIA annexes; a DPIA programme (the systematic, repeatable DPIA pipeline); a SoA reconciled across entities and across the integrated ISMS; an enterprise risk-management integration; SDF-level DPIP / independent-audit / algorithmic-fairness programmes. Typically 6 to 10 months for the first cycle, with an embedded privacy-risk capability.

By PIMS role

PII controller (Data Fiduciary) primary. The risk register leads with the controller-side risks: the consent-quality risks, the notice-quality risks, the rights-handling risks, the cross-border-transfer risks, the children's-data risks, the section 10 SDF risks if applicable. The DPIA register leads with the controller-side triggers. The SoA leads with the Annex A.1 controls.

PII processor (Data Processor) primary. The risk register leads with the processor-side risks: the instruction-handling risks (the infringing-instruction risk under Annex A.2.2.5), the sub-processor-management risks (the change-notice, the audit-cooperation, the return/deletion), the breach-notification-to-controller risks, the cross-border-transfer-chain risks. The SoA leads with the Annex A.2 controls.

Both controller and processor. The most common shape for Indian growing companies. The risk register addresses both risk sets and the boundary between them, which risks are controller-side (the organisation's own principals), which are processor-side (the customer's principals reached through the organisation's processing), where the boundary is contested (joint-controller arrangements under Annex A.1.2.8 / GDPR Article 26).

By sector

Sector-specific overlays are addressed in Section 21. The headline sectors, BFSI, Healthcare, IT-ITeS, E-commerce, Edtech, Manufacturing, each carry distinctive risk profiles (RBI localisation and digital-lending for BFSI; health-data sensitivity and clinical-data confidentiality for Healthcare; customer-data scale and cross-border processor chains for IT-ITeS; consumer-privacy expectations and children's-data for E-commerce; verifiable parental consent and the section 9 regime for Edtech; OT-IT convergence and the supply-chain processor ecosystem for Manufacturing).

Key Definitions and Terminology

Privacy risk. The combination of the likelihood of a privacy harm to a PII principal and the severity of that harm, given the potential threats and the controls in place. The 2025-edition load-bearing point: privacy risk is measured primarily by the impact on the principal, not the impact on the organisation.

Privacy harm. The adverse effect on a PII principal from the processing of their personal data, including loss of autonomy, distress, financial loss, identity theft, physical or psychological harm, discrimination, and the inability to exercise rights. The harm taxonomy is the principal-impact axis.

PII principal / Data Principal / data subject. The individual to whom the personal data relates. DPDP Act 2023 section 2(1)(h); GDPR Article 4(1); ISO/IEC 29100. The principal is the subject of the privacy risk; the principal-impact axis measures the risk to the principal.

Risk source. The element that alone or in combination has the potential to give rise to a privacy risk, a processing activity, a threat actor, a vulnerability, a third party, a regulatory change, a contract breach, a system failure, a human error.

Threat. A potential cause of an unwanted incident that may result in harm to a PII principal, the external attacker, the malicious insider, the careless employee, the misconfigured system, the failed sub-processor.

Vulnerability. A weakness in an asset or control that can be exploited by a threat, the missing encryption, the over-broad access, the stale consent record, the unpatched system, the unsigned DPA.

Likelihood. The chance that a threat materialises, given the controls in place. Qualitative scales (rare / unlikely / possible / likely / almost certain) are the most common; quantitative scales (annualised frequency) are mature-programme territory.

Impact (principal). The severity of the harm to the PII principal if the risk materialises. The principal-impact rating considers autonomy, dignity, financial standing, safety, non-discrimination and rights.

Impact (organisation). The severity of the harm to the organisation if the risk materialises, operational disruption, regulatory penalty (DPDP Schedule, GDPR Article 83 maxima, sectoral penalties), contractual breach, reputational damage.

Inherent risk. The risk level before treatment, the likelihood × impact rating assuming no controls. The starting point of the analysis.

Residual risk. The risk level after treatment, the likelihood × impact rating given the controls in operation. The ending point of the analysis; the discipline that proves the treatment is effective.

Risk criteria. The documented thresholds against which the analysed risk is evaluated, the risk-acceptance threshold (below which risks are auto-accepted), the risk-tolerance threshold (above which risks must be treated), the risk-appetite threshold (the upper bound the organisation will not exceed). The risk criteria must be documented; an undocumented rating does not satisfy 6.1.2.

Risk owner. The person or entity with the authority and the accountability to manage a risk. Risk ownership follows the processing-activity ownership, the business-process owner is the canonical risk owner.

Treatment option. The selected response to a material risk, modify (apply controls), retain (accept), avoid (terminate the processing activity), share (transfer, typically via insurance or contractual allocation). The four options inherit from ISO 31000 / ISO/IEC 27005.

PIMS Statement of Applicability (SoA). The 6.1.3 artefact that cross-walks every Annex A.1, A.2 and A.3 control to (a) applicability status, (b) justification, (c) current-state implementation evidence, (d) exclusion reasoning.

DPIA / DPIP. Data Protection Impact Assessment (GDPR Article 35 language) / Data Protection Impact Procedure (DPDP Act section 10 language). The deeper, structured analysis required when a trigger fires (Article 35(1) high risk; DPDP section 10 SDF; ISO/IEC 29134). The DPIA follows the 29134 / Article 35(7) structure: systematic description, necessity and proportionality, principal-impact, mitigations, residual risk, consultation.

Trigger test. The documented decision process that determines whether a processing activity requires a DPIA. The test draws from DPDP section 10 (for SDFs), GDPR Article 35 + WP248 rev.01 (for EU/EEA processing) and ISO/IEC 29134 (for the international baseline).

Risk-acceptance record. The signed record that a risk above the risk-acceptance threshold has been accepted by the risk owner, with the rationale, the conditions and the review date.

Risk-treatment plan (RTP). The 6.1.3 artefact that records, for each material risk, the selected treatment option, the controls selected, the implementation owner, the target date, the resource estimate and the residual-risk projection.

Integrated-with-distinction posture. The Singahi-recommended pattern where the privacy risk assessment and the infosec risk assessment share one governance, one register backbone and one SoA, but maintain two distinct impact axes (principal-impact and organisational-impact) and two distinct control surfaces (Annex A.1 / A.2 / A.3 for privacy; ISO/IEC 27002:2022 Annex A for security).

Relationship to Other Clauses and Frameworks

Inside ISO/IEC 27701:2025

• 4.1 (context): the issues identified drive the risk landscape, every issue generates candidate risks.
• 4.2 (interested parties): the requirements register is the canonical risk source, non-compliance with a requirement is the canonical privacy risk.
• 4.3 (scope): defines the risk-assessment boundary.
• 4.4 (the PIMS): shaped by the risk treatment decisions.
• 5.1, 5.2, 5.3 (leadership, policy, roles): the policy commits to risk-based privacy; the roles include the risk owners.
• 6.2 (objectives): calibrated to the residual-risk trajectory, e.g., a KPI on residual-risk reduction cycle-on-cycle.
• 6.3 (changes): triggered by risk-event realisations or by methodology upgrades.
• 7.2 (competence): the risk methodology competence is a 7.2 requirement; the DPO, the CISO and the process owners must be trained on the methodology.
• 7.3 (awareness): staff trained on the material risks.
• 7.4 (communication): internal and external communication about risks, the board, the regulator, the principals.
• 7.5 (Documented Information): the methodology, the register, the DPIAs, the SoA, the RTP, the acceptance log.
• 8.1 to 8.3 (operation): the operational processes implement the treatment plan; the ROPA (Clause 8.2) feeds the risk register.
• 8.2 (the deeper operational privacy risk assessment): the Clause 8.2 risk assessment is the operational expression of the 6.1.2 methodology, the ROPA, the per-processing-activity risk evaluation.
• 9.1 (monitoring): tests the residual-risk trajectory and the effectiveness of the controls.
• 9.2, 9.3 (audit, review): test the methodology, the register, the DPIAs and the SoA.
• 10.1, 10.2 (improvement, corrective action): respond to risk realisations and improve the methodology.
• Annex A.1 (controllers), A.2 (processors), A.3 (security): the control menu the SoA draws from. Annex A.1.2.5 (privacy impact assessment) is the DPIA cross-reference.

Cross-framework

• ISO/IEC 27001:2022 Clause 6.1 (Actions to address risks and opportunities), structurally identical on the infosec side; the integrated-with-distinction posture uses the shared structure.
• ISO/IEC 27005:2022 (Information security risk management), the methodological reference for the infosec risk-assessment tradition; the privacy methodology inherits the ISO 31000 vocabulary.
• ISO/IEC 29134:2017 (Guidelines for privacy impact assessment), the methodological reference for the DPIA tradition; the deeper 6.1.2 analysis follows the 29134 structure.
• ISO/IEC 27557 (Impact assessment), the impact-assessment criteria reference.
• ISO 31000:2018 (Risk management), the umbrella vocabulary and the four-treatment-option source (modify / retain / avoid / share).
• GDPR Article 35 (DPIA), Article 36 (prior consultation), Article 24 (controller responsibility), Article 32 (security), Article 5(2) (accountability), the external anchors for the EU-relevant processing. The Article 29 WP248 rev.01 nine-criteria DPIA-trigger list is the operational expression of Article 35(1).
• NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), Identify-P function (data mapping, business environment, risk assessment, data lifecycle), the US-flavoured structural analogue of the 6.1.2 methodology.
• NIST SP 800-37 Rev. 2 (Risk Management Framework for Information Systems and Organizations), the US federal risk-management tradition.
• SOC 2 (AICPA TSC 2017), CC3.1, CC3.2, CC3.3 (Risk identification, assessment, response), the SOC 2 view of the risk discipline. The Privacy category P-criteria depend on the risk assessment.
• DPDP Act 2023, section 8(5) reasonable security safeguards; section 8(6) breach notification; section 9 children; section 10 SDF (DPO + DPIP + independent audit + algorithmic-AI fairness); section 11 rights; section 13 grievance; section 16 transfer; section 33 + Schedule penalties. The DPDP is the load-bearing regulatory input to the Indian privacy risk register.

Inside the harmonized structure, what 6.1 inherits

The harmonized structure (HS, formerly Annex SL) is the shared skeleton ISO uses for management-system standards. 27701:2025, 27001:2022, 22301:2019, 9001:2015, 14001:2015, 45001:2018, 42001:2023 all use it. For 6.1, this means:

• The clause text is structurally identical across all HS standards, only the subject-matter load differs.
• An organisation running an integrated 27001 + 27701 + 42001 programme can run a single combined risk methodology with sub-sections for each discipline.
• The treatment-option taxonomy (modify / retain / avoid / share) is common.
• The risk-criteria vocabulary (inherent / residual; likelihood × impact; risk appetite; risk acceptance) is common.

The Singahi integrated privacy-risk assessment procedure (toolkit doc 02) supports the HS-combined pattern: a single methodology with columns tagging each risk as ISMS-relevant, PIMS-relevant, AIMS-relevant, BCMS-relevant, or shared.

Detailed Implementation Guidance, The Six Risk Moves

Figure · Process

What Clause 6.1 asks you to do

Move 1, Decide the relationship between the privacy risk assessment and the infosec risk assessment

This is the most consequential decision and the most-flagged certification NC zone. The choice is between three patterns.

Pattern A, Integrated-with-distinction (Singahi recommended default). One risk register, one methodology, one SoA, but two distinct impact axes (principal-impact and organisational-impact) and two distinct control surfaces (Annex A.1 / A.2 / A.3 for privacy; ISO/IEC 27002:2022 for security). The DPO and the CISO co-author the methodology. The integrated posture is the most efficient for organisations running an integrated ISMS+PIMS programme, which is most Indian growing companies.

Pattern B, Parallel with reconciliation. Two registers, two methodologies, two SoAs, with a documented reconciliation that proves the two control surfaces agree on the same processing activity. Heavier operationally; defensible where the two functions sit in different teams with different governance. The risk is non-reconciliation, the two registers disagree, the two SoAs disagree, the audit identifies the discrepancy.

Pattern C, Reskin (avoid). One register with a privacy label added; the principal-impact axis missing; the DPIA triggers not tested; the A.1 / A.2 control surface invisible. The single most common 6.1 finding in the Indian growing-company segment.

The decision is recorded in the Privacy Risk Assessment Procedure (toolkit doc 02 Section 4). The default for most growing companies is Pattern A; the migration to Pattern A from Pattern B is the most common maturity-upgrade move; the migration from Pattern C is the most common remediation move.

Move 2, Stand up the risk-assessment workshop

Convene a full-day workshop with the executive sponsor (CEO/MD/COO), the DPO / Privacy Lead, the CISO / Security Lead, the Head of Legal, and the business-process owners for the top 10 processing activities (the product owner, the marketing lead, the HR lead, the operations lead, the customer-support lead, the engineering lead). The workshop has four outputs: the Privacy Risk Assessment Procedure (the methodology), the populated risk register for the top 10 processing activities, the DPIA trigger test results, and the SoA draft.

The workshop uses the Singahi toolkit templates (docs 01, 02, 03, 09) on a shared spreadsheet. Time-box each processing activity to 30 minutes, describe the activity (use the ROPA entry as the input), identify the candidate risks, rate the principal-impact and the organisational-impact, rate the likelihood, calculate the inherent risk, identify the candidate controls, project the residual risk, decide the treatment option, decide the DPIA trigger, move on.

Move 3, Build the Privacy Risk Assessment Procedure

The Procedure is the methodology artefact. It must cover:

• Scope, the processing activities, the data types, the business units, the jurisdictions, the controller/processor roles in scope. Reconciled with the Clause 4.3 PIMS scope.
• Inputs, the issues from 4.1, the requirements from 4.2, the ROPA from Clause 8, the threat landscape (industry threat intelligence, CERT-In advisories, sector-specific signals), the historical incident register (the organisation's own breach history), the audit findings.
• Risk-identification method, the structured way candidate risks are surfaced (the processing-activity-centric method is the Singahi default; for each in-scope processing activity, the workshop identifies the candidate risk sources, threats, vulnerabilities and harm scenarios).
• Risk-analysis method, the documented likelihood × impact methodology, with separate ratings for principal-impact and organisational-impact. The Singahi principal-impact scale (autonomy, dignity, financial standing, safety, non-discrimination, rights) is the load-bearing addition over the infosec tradition.
• Risk-evaluation method, the documented risk criteria (risk-acceptance threshold, risk-tolerance threshold, risk-appetite threshold) against which the analysed risks are evaluated.
• DPIA trigger test, the documented decision tree that determines whether a processing activity requires a DPIA (DPDP section 10 for SDFs; GDPR Article 35 + WP248 for EU/EEA processing; ISO/IEC 29134 for the international baseline).
• Treatment-option taxonomy, the modify / retain / avoid / share four-option decision, with the per-risk selection documented.
• Relationship to the infosec risk assessment, Pattern A, B or C (Move 1 above).
• Roles, the DPO, the CISO, the business-process owner, the risk owner, the internal audit, the management review.
• Cadence, annual review at the management review; event-trigger review on new processing activity, new sub-processor, new jurisdiction, new regulation, post-incident.
• Documented Information control, version, approval, retention (Clause 7.5).

The Singahi Privacy Risk Assessment Procedure template (toolkit doc 02) provides the structure with all 11 sections pre-populated for customisation.

Move 4, Build the privacy risk register

The register is the operational artefact the Procedure produces. Each row records:

• Risk ID, unique identifier.
• Processing activity, the ROPA entry that generates the risk.
• Risk source, the element that has the potential to give rise to the risk.
• Threat, the potential cause of the unwanted incident.
• Vulnerability, the weakness that can be exploited.
• Harm scenario, the description of how the principal could be harmed.
• Affected PII principal class, the population of principals at risk (with vulnerability flags for children, employees, persons with disability).
• Principal-impact rating, the severity of the harm to the principal (autonomy, dignity, financial standing, safety, non-discrimination, rights), low / medium / high / severe.
• Organisational-impact rating, the severity of the harm to the organisation (operational, regulatory, contractual, reputational), low / medium / high / severe.
• Likelihood, rare / unlikely / possible / likely / almost certain.
• Inherent risk rating, the likelihood × impact combination (low / medium / high / critical).
• Treatment option, modify / retain / avoid / share.
• Controls applied, the Annex A.1 / A.2 / A.3 controls selected (cross-referenced to the SoA).
• Residual risk rating, the post-treatment rating (low / medium / high / critical).
• Risk owner, the named individual.
• Risk-acceptance record, signed if residual risk is above the acceptance threshold.
• Review date, the next scheduled review.
• DPIA required, yes / no (per the trigger test); if yes, the DPIA register ID.

Typical risk register sizes for Indian growing companies: 30 to 80 entries (50 to 250 staff); 80 to 250 (mid-market); 250 to 1,500+ (enterprise).

Move 5, Run the DPIA / DPIP trigger test and the DPIA pipeline

For each in-scope processing activity, run the trigger test. The Singahi trigger test (toolkit doc 02 Section 6) draws from three sources in a single decision tree:

• DPDP section 10 (for SDFs): is the organisation a Significant Data Fiduciary? If yes, the DPIP is mandatory for every new processing activity; the DPIA register covers the full processing-activity set.
• GDPR Article 35 + WP248 rev.01 (for EU/EEA processing): does the processing meet any two of the nine criteria? The criteria: evaluation or scoring (including profiling and prediction); automated decision-making with legal or similar significant effect; systematic monitoring; sensitive data or data of a highly personal nature; data processed on a large scale; matching or combining datasets; vulnerable data subjects; innovative use or applying new technological solutions; data transfer outside the EU without adequacy. If yes, the DPIA is mandatory.
• ISO/IEC 29134 (for the international baseline): does the processing meet the 29134 triggers (large-scale, sensitive, systematic, novel, vulnerable subjects)? If yes, the PIA is recommended.

For each triggered processing activity, run the DPIA. The DPIA follows the 29134 / Article 35(7) structure:

• Systematic description of the processing (the flows, the data, the purposes, the retention, the recipients).
• Context of the processing (the business, the technology, the parties, the geography).
• Necessity and proportionality test, is the processing necessary for the purpose? Is the data minimised? Is the retention proportionate? Are there less intrusive alternatives?
• Principal-impact analysis, the harm scenarios, the affected principal classes, the severity ratings.
• Risk evaluation, the inherent risk rating, the controls in place, the residual risk rating.
• Mitigations, the additional controls selected to bring the residual risk within the risk-appetite threshold.
• Consultation record, where the residual risk remains high, the consultation with the Data Protection Board of India (under DPDP) or the supervisory authority (under GDPR Article 36).

The Singahi DPIA template (toolkit doc 09) is the load-bearing artefact, pre-populated with the 29134 / Article 35(7) structure, the DPDP section 10 DPIP-specific fields, the principal-impact scale, the consultation record template.

Move 6, Produce the PIMS Statement of Applicability

The SoA is the 6.1.3 artefact. It cross-walks every Annex A.1, A.2 and A.3 control to:

• Applicability status, applicable / not applicable.
• Justification, the risk or the requirement the control treats, with the risk-register ID or the requirements-register ID.
• Implementation state, current-state, not future-state. A control marked applicable where the implementation is planned but not yet in operation is a nonconformity. The implementation state must reflect the operational reality on the audit day.
• Evidence reference, the policy, procedure, ROPA entry, contract, technical control configuration, training record, or other artefact that proves the control is in operation.

The SoA must also document the exclusions with reasoning, every control marked \"not applicable\" must have a documented justification. The canonical exclusion-justification failure is the control marked applicable on a hypothetical future relationship (\"we may have a joint controller next year\", flagged in tier-1 practitioner commentary as a common NC). The SoA reflects the current operational reality, not the future intention.

The SoA draws from the full Annex A: 31 A.1 controls (controller), 18 A.2 controls (processor), approximately 29 A.3 controls (security, aligned to ISO/IEC 27002:2022), 78 controls in the consensus count. For each, the applicability test asks: does the organisation act in the role (controller for A.1, processor for A.2, either for A.3) and does the control treat a material risk or satisfy a material requirement?

The Singahi PIMS Statement of Applicability template (toolkit doc 03) is the load-bearing artefact, pre-populated with all 78 Annex A controls (per the 2025-edition enumeration), the applicability-justification columns, the current-state implementation columns, and the exclusion-reasoning columns.

Worked example, Tarini Fintech integrated privacy-risk redesign

To make the six moves concrete, consider Tarini Fintech (a fictional Mumbai-based digital-lending platform; the facts are composite from publicly reported sector patterns and should not be attributed to any real organisation). Tarini Fintech's first 6.1 cycle surfaced:

• Pattern decision: Pattern A (integrated-with-distinction). The DPO and the CISO co-authored the methodology; the existing ISMS risk register was extended with the principal-impact axis and the Annex A control surface.
• Top-10 processing activities risk-assessed: the loan-application flow (controller); the credit-scoring engine (controller, AI-driven); the customer-support tooling (controller); the marketing-lead scoring (controller, AI-driven); the cross-border analytics flow (controller, transfer to a US analytics sub-processor); the collections-call recordings (controller, sensitive); the employee-monitoring tool (controller); the payments-sub-processor chain (controller via the Payment Aggregator licence); the processor-side customer-data plane (processor for the BNDF partner banks); the co-branded credit-card JV (joint controller with the card-issuer bank).
• Risk register: 142 entries across the 10 activities. The highest-rated risks: the credit-scoring engine's algorithmic bias (principal-impact: severe on the non-discrimination dimension; organisational-impact: high under the RBI Digital Lending Guidelines and the DPDP section 10 algorithmic-fairness review); the cross-border analytics flow (principal-impact: high on the autonomy and rights dimensions; organisational-impact: high under the DPDP section 16 negative list and GDPR Chapter V); the collections-call recordings (principal-impact: high on the dignity dimension; organisational-impact: medium).
• DPIA / DPIP register: 7 processing activities triggered the DPIA. The credit-scoring engine DPIA identified the algorithmic-bias risk as residual-high; the consultation record triggered a proactive engagement with the RBI and a planned DPBI consultation (DPDP section 10). The cross-border analytics flow DPIA identified the transfer-impact-assessment gap; the treatment included supplementary measures (encryption-in-transit, pseudonymisation, the standard contractual clauses) and the residual risk was brought within the risk-appetite threshold.
• PIMS SoA: 78 Annex A controls cross-walked. 52 applicable (current-state evidenced); 26 not applicable (with documented exclusion reasoning, e.g., A.2.2.x processor controls not applicable where Tarini was not acting as a processor for that activity; A.1.4.6 de-identification applicable with the pseudonymisation treatment as evidence; A.1.5.4 transfer records applicable with the cross-border transfer register as evidence).
• Risk-acceptance log: 4 entries signed by the respective risk owners above the acceptance threshold (the credit-scoring engine residual-high pending the algorithmic-fairness review completion; the employee-monitoring tool residual-medium pending the works-council consultation; the BNDF partner-bank processor-side residual-medium pending the contract refresh; the legacy-collection-call-recording archive residual-high pending the migration to the new consent-aware platform).

The first-cycle effort: 16 weeks of internal time plus external advisory; the resulting artefact set passed Stage 1 audit at first attempt; the integrated-with-distinction posture avoided the parallel-pattern reconciliation overhead; the DPIA register positioned Tarini for the SDF designation analysis (which was triggered later that year when Tarini crossed the SDF volume threshold).

The risk-monitoring discipline in more depth

The register is only as good as its currency. Three patterns dominate. Pattern A, Annual update only (the default for compact organisations): the register is updated in the 30 days before the management review; suitable for a stable processing-activity set and a small threat surface. Pattern B, Event-trigger update (the discipline most organisations should run): the register is updated whenever a material event fires (new processing activity, new sub-processor, new jurisdiction, new regulation, post-incident, audit finding, methodology upgrade); the DPO maintains a change-monitoring log and convenes the workshop on trigger. Pattern C, Continuous monitoring (the discipline for SDFs, listed entities, and large enterprises): the register is monitored continuously through a threat-intelligence subscription, a processor-change feed, a regulatory-intelligence feed, and a stakeholder-engagement programme; the workshop is convened on trigger. The Singahi privacy-risk-monitoring procedure (toolkit doc 02 Section 9) operationalises all three patterns.

Tools, Technologies, and Solutions

The tool categories

Privacy risk-management platforms. GRC modules that record the privacy risk register, the DPIA register, the SoA, the RTP and the acceptance log. Generic descriptions: a GRC platform with a privacy-risk module that supports the integrated-with-distinction posture; a DPIA-automation tool that pre-populates the systematic description from the ROPA and routes the analysis to the DPO and the process owner.

ROPA / processing-activity discovery tools. Tools that scan the data estate to surface processing activities the organisation may not have documented. Generic descriptions: a data-mapping platform that automates the ROPA discovery; a processing-activity-inventory tool.

Threat-intelligence feeds. CERT-In advisories, sector-specific feeds, industry threat intelligence. Relevant for the likelihood axis and the risk-source identification.

DPIA workflow tools. Specialised DPIA platforms that operationalise the 29134 / Article 35(7) structure with templates, routing, and the consultation record.

Consent and preference management platforms. Operational tools that implement the consent controls (A.1.2.3, A.1.2.4, A.1.3.5) and feed evidence back into the SoA.

Cross-border transfer monitoring. Tools that track the actual cross-border data flows against the documented transfer register; surface untracked flows; flag the transfer-impact-assessment refresh.

Selection criteria

Select on: India-DPDP coverage (most global platforms are GDPR-heavy and DPDP-thin); integrated-with-distinction support (the ability to maintain the principal-impact axis alongside the organisational-impact axis in a single register); DPIA-automation depth (the 29134 / Article 35(7) structure as a first-class artefact, not a free-form text field); SoA support (the ability to cross-walk Annex A controls with current-state evidence); integration with the existing GRC stack; alert quality (low false-positive rate); and cost-to-value for the Indian growing-company segment.

Build vs buy

Most growing companies should buy the GRC platform and the consent platform and build the risk methodology in-house with external advisory for the first cycle. The methodology is too organisation-specific to outsource end-to-end; the tooling is too time-intensive to build internally.

Indicative cost ranges (India, mid-market, annual)

• Independent data audit (mandatory for SDFs under DPDP section 10): 8 to 30 lakh rupees per audit cycle.

Policy and Procedure Templates

Privacy Risk Management Policy (sample of our own drafting)

The organisation maintains a Privacy Risk Management methodology as a living Documented Information artefact that records the relationship between the privacy risk assessment and the infosec risk assessment (integrated-with-distinction pattern), the risk-identification, risk-analysis and risk-evaluation methods, the principal-impact and organisational-impact axes, the DPIA trigger test, the treatment-option taxonomy, the risk criteria, the risk-acceptance threshold and the review cadence. The DPO and the CISO jointly own the methodology. The DPO maintains the Privacy Risk Register, the DPIA / DPIP Register, the PIMS Statement of Applicability, the Risk Treatment Plan and the Risk-Acceptance Log as Documented Information per Clause 7.5. Each material risk is owned by the business-process owner for the processing activity that generates the risk. The DPO reports the residual-risk trajectory to the management review (Clause 9.3).

Risk-Acceptance Policy (sample of our own drafting)

Risks above the documented risk-acceptance threshold require a signed risk-acceptance record by the named risk owner. The risk-acceptance record includes the risk description, the principal-impact rating, the organisational-impact rating, the residual-risk rating, the rationale for acceptance, the conditions (including the review date and the mitigation commitments), and the named risk owner's sign-off. The DPO maintains the Risk-Acceptance Log and reports the open acceptance record count to the management review. Risks above the risk-appetite threshold (the upper bound) are not eligible for acceptance and must be treated to bring the residual risk within the appetite.

Privacy Risk Assessment Procedure (sample of our own drafting, summarised)

1. Scope and inputs, the Procedure applies to every in-scope processing activity in the PIMS scope (Clause 4.3); the inputs are the issues from 4.1, the requirements from 4.2, the ROPA from Clause 8, the threat-intelligence feed, the historical incident register, and the audit findings.
2. Risk identification, for each processing activity, the workshop identifies the candidate risk sources, threats, vulnerabilities and harm scenarios; the output is a candidate-risk list per activity.
3. Risk analysis, for each candidate risk, the workshop rates the likelihood (rare to almost certain), the principal-impact (low to severe across the six dimensions), and the organisational-impact (low to severe across the four dimensions); the inherent risk is the combination.
4. Risk evaluation, the inherent risk is compared against the risk criteria (acceptance, tolerance, appetite thresholds) and rated low / medium / high / critical.
5. DPIA trigger test, for each processing activity, the trigger test (DPDP section 10 + GDPR Article 35 + ISO/IEC 29134) determines whether a DPIA is required.
6. Treatment-option selection, for each material risk, the workshop selects the modify / retain / avoid / share option with documented reasoning.
7. Control selection, for the modify option, the workshop selects the Annex A.1 / A.2 / A.3 controls (cross-referenced to the SoA).
8. Residual-risk projection, the workshop projects the residual risk given the selected controls.
9. Risk-owner sign-off, the named risk owner signs off on the residual-risk rating and the treatment plan.
10. SoA update, the SoA is updated to reflect the control applicability decisions.
11. Risk-acceptance record, for residual risks above the acceptance threshold, the risk owner signs the acceptance record.
12. Documented Information control, the Procedure, the register, the DPIAs, the SoA, the RTP and the acceptance log are controlled per Clause 7.5.
13. Cadence, annual review at the management review; event-trigger review on new processing activity, new sub-processor, new jurisdiction, new regulation, post-incident.

DPIA / DPIP Procedure (sample of our own drafting, summarised)

1. Trigger, the trigger test (Procedure step 5 above) fires.
2. Convene the DPIA team, the DPO, the process owner, the CISO, Legal, and (where AI-driven) the algorithmic-fairness reviewer.
3. Systematic description, describe the processing (flows, data, purposes, retention, recipients).
4. Context, describe the business, technology, parties, geography.
5. Necessity and proportionality, test whether the processing is necessary for the purpose, the data is minimised, the retention is proportionate, less-intrusive alternatives are considered.
6. Principal-impact analysis, rate the harm scenarios and the affected principal classes across the six dimensions.
7. Risk evaluation, inherent risk, controls in place, residual risk.
8. Mitigations, additional controls to bring the residual risk within the appetite.
9. Consultation record, where residual risk remains high, consult the Data Protection Board of India (under DPDP) or the supervisory authority (under GDPR Article 36); record the consultation.
10. DPO sign-off, the DPO signs the DPIA.
11. Risk-owner acceptance, the risk owner signs the residual-risk acceptance.
12. Review, the DPIA is reviewed annually or on material change.

Statement of Applicability Policy (sample of our own drafting)

The organisation maintains a PIMS Statement of Applicability as a living Documented Information artefact that cross-walks every Annex A.1, A.2 and A.3 control to its applicability status (applicable / not applicable), its justification (the risk or the requirement it treats), its implementation state (current-state, evidenced), and its exclusion reasoning (where not applicable). The SoA is updated on every risk-register change, every DPIA completion, every new or amended requirement, and at the annual management review. The DPO owns the SoA; the CISO co-owns the A.3 security-control evidence; the business-process owners own the A.1 / A.2 control evidence for their processing activities. The SoA does not document future-state controls; controls marked applicable where the implementation is planned but not in operation are nonconformities.

Integrated-with-Distinction Statement (sample of our own drafting)

The organisation runs the privacy risk assessment and the infosec risk assessment under a single methodology with two distinct impact axes (principal-impact and organisational-impact) and two distinct control surfaces (ISO/IEC 27701:2025 Annex A and ISO/IEC 27002:2022 Annex A). The DPO and the CISO jointly own the methodology. The risk register is a single artefact with the principal-impact and organisational-impact columns populated for every privacy-relevant risk. The Statement of Applicability is a single document covering both control surfaces with a clear cross-walk between the privacy controls (Annex A.1 / A.2 / A.3) and the security controls (ISO/IEC 27002:2022).

Risk Assessment and Treatment

This section is the operational core of Clause 6.1. It expands on the methodology introduced in Section 7 and provides the worked detail for the principal-impact axis, the DPIA depth, the four treatment options, the SoA discipline and the risk-acceptance record.

The principal-impact rating scale (the load-bearing addition)

The principal-impact rating is the load-bearing addition of the privacy risk assessment over the infosec risk assessment. The Singahi principal-impact scale (toolkit doc 02 annex A) rates the severity of the harm to the PII principal across six dimensions:

The principal-impact rating for a given risk is the highest rating across the six dimensions. A risk that rates \"severe\" on any dimension is rated severe overall; a risk that rates \"high\" on any dimension (with no severe) is rated high overall; and so on. The principal-impact rating is recorded alongside the organisational-impact rating in the risk register; the inherent-risk rating is the combination of the principal-impact (primary), the organisational-impact (secondary), and the likelihood.

The Singahi principal-impact scale is calibrated to the DPDP Act's harm-oriented framing (the penalty Schedule reflects the harm severity) and to the GDPR Article 35(1) \"high risk to the rights and freedoms of natural persons\" trigger.

The DPIA / DPIP register

The DPIA / DPIP register is the artefact that records, for every processing activity that triggered the DPIA test, the DPIA result. The Singahi DPIA template (toolkit doc 09) is the load-bearing artefact, pre-populated with the 29134 / Article 35(7) structure, the DPDP section 10 DPIP-specific fields, the principal-impact scale, the consultation record template.

The DPIA register fields:

• DPIA ID, unique identifier.
• Processing activity, the ROPA entry.
• Trigger source, DPDP section 10 (SDF) / GDPR Article 35 / ISO/IEC 29134.
• Trigger criteria, the specific criteria that fired (e.g., for WP248, the two-of-nine combination).
• DPIA team, the DPO, the process owner, the CISO, Legal, the algorithmic-fairness reviewer (where AI-driven).
• Systematic description, the flows, data, purposes, retention, recipients.
• Context, the business, technology, parties, geography.
• Necessity and proportionality, the test result.
• Principal-impact analysis, the harm scenarios, affected principal classes, severity ratings.
• Risk evaluation, inherent risk, controls in place, residual risk.
• Mitigations, additional controls selected.
• Consultation record, the DPBI / supervisory authority consultation where residual risk remains high.
• DPO sign-off, date, signature.
• Risk-owner acceptance, date, signature.
• Review date, annual or on material change.

Typical DPIA register sizes for Indian growing companies: 3 to 10 DPIAs (50 to 250 staff); 10 to 30 (mid-market); 30 to 500+ (enterprise / SDF).

The four treatment options, the worked detail

The four treatment options inherited from ISO 31000 / ISO/IEC 27005 are:

Option 1, Modify (apply controls). The canonical option for most privacy risks. The modify option selects controls from Annex A.1 (controller), A.2 (processor) and A.3 (security) to reduce the likelihood or the principal-impact / organisational-impact. Examples: a marketing-lead scoring engine that triggers the WP248 \"evaluation or scoring\" criterion is modified by the A.1.4.5 (PII minimisation) and A.1.4.10 (PII transmission controls) controls plus the algorithmic-fairness review; a cross-border analytics flow is modified by the A.1.5.2 (basis for PII transfer), the supplementary measures (encryption, pseudonymisation), and the standard contractual clauses; a collections-call recording is modified by the A.1.4.7 (temporary files) and the explicit consent capture.

Option 2, Retain (accept the residual risk). The option for residual risks above the acceptance threshold where modify is not cost-effective or avoid is not commercially viable. Requires a signed risk-acceptance record by the named risk owner. Example: an employee-monitoring tool with a residual-medium rating is retained pending the works-council consultation; the risk owner (the HR lead) signs the acceptance record with a 6-month review date and a mitigation commitment (the consultation completion).

Option 3, Avoid (terminate the processing activity). The option for risks that exceed the risk appetite and cannot be modified. Example: a behavioural-monitoring feature on a K-12 platform that triggers the DPDP section 9 prohibition on behavioural monitoring of children, the only defensible treatment is avoid; the feature is terminated.

Option 4, Share (transfer part of the risk). The option to transfer part of the risk through insurance (cyber-insurance with privacy-liability coverage) or through contractual allocation (the processor agreement's indemnity, the sub-processor's liability cap, the joint-controller arrangement's responsibility allocation). Share does not eliminate the risk; it allocates the financial consequence. The principal-impact is not transferable, the organisation remains accountable to the principal regardless of the contractual allocation.

The PIMS Statement of Applicability, the worked detail

The SoA is the load-bearing 6.1.3 artefact. The Singahi PIMS SoA template (toolkit doc 03) provides the structure with all 78 Annex A controls pre-populated. The SoA fields per control:

• Control ID, A.1.2.2, A.1.2.3, ..., A.3.30 (per the 2025-edition enumeration in research/08).
• Control title, paraphrased from the standard (no verbatim text).
• Applicability status, applicable / not applicable.
• Justification, the risk-register ID or the requirements-register ID that the control treats or satisfies.
• Implementation state, current-state: fully implemented / partially implemented / planned.
• Evidence reference, the policy, procedure, ROPA entry, contract, technical control configuration, training record, or other artefact.
• Owner, the named individual accountable for the control's operation.
• Last review date, when the control's operation was last verified.
• Exclusion reasoning, for non-applicable controls, the documented justification.

The current-state discipline is the most-violated SoA rule. A control marked applicable where the implementation is planned but not yet in operation is a nonconformity. The SoA reflects the operational reality on the audit day; planned controls are documented in the Risk Treatment Plan, not in the SoA.

The exclusion-reasoning discipline is the second-most-violated rule. A control marked not-applicable must have a documented justification. The canonical failure (flagged in tier-1 practitioner commentary) is the joint-controller control (A.1.2.8) marked applicable on a hypothetical future relationship, \"we may have a joint controller next year\". The SoA reflects the current operational reality; future relationships are documented in the opportunity axis of the Procedure.

The risk-acceptance record

The risk-acceptance record is the artefact that captures, for every risk above the risk-acceptance threshold, the formal sign-off by the named risk owner. The Singahi Risk-Acceptance Log (toolkit doc 02 annex C) records:

• Risk ID, the risk-register entry.
• Risk description, the candidate risk retained.
• Principal-impact rating, the severity on the principal.
• Organisational-impact rating, the severity on the organisation.
• Residual-risk rating, the post-treatment rating.
• Rationale for acceptance, why the risk is retained rather than modified further or avoided.
• Conditions, the mitigation commitments, the review date, the monitoring commitments.
• Risk owner, the named individual.
• Sign-off date, the formal acceptance.
• Review date, the next scheduled review of the acceptance.

The risk-acceptance log is reported to the management review (Clause 9.3). The open-acceptance-record count is a KPI (Section 12 KPI 14).

The 6.1 risk register (the consolidated view)

The high-impact, high-likelihood risks to treat first are: the DPIA missing for a triggered processing activity; the reskin-pattern failure; the breach-notification clock missed; the consent-quality failure. These four risks account for most of the 6.1 audit nonconformities in the Indian growing-company segment.

Audit and Compliance Checklist

The 28 questions below cover the audit-evidence surface for Clause 6.1. Expected evidence and red flags noted. Most can be answered from the toolkit doc 04 audit-evidence checklist.

1. Is there a Privacy Risk Assessment Procedure (the methodology artefact)? Expected: dated, version-controlled, signed by top management or the DPO with sponsor authority. Red flag: missing.
2. Does the Procedure document the relationship to the infosec risk assessment (Pattern A / B / C)? Red flag: pattern not documented (reskin-pattern risk).
3. Does the Procedure include the principal-impact axis as the primary impact measure?
4. Does the Procedure document the risk-identification, risk-analysis and risk-evaluation methods?
5. Does the Procedure document the risk criteria (acceptance, tolerance, appetite thresholds)?
6. Does the Procedure document the DPIA trigger test (DPDP section 10 + GDPR Article 35 + ISO/IEC 29134)?
7. Does the Procedure document the four-treatment-option taxonomy?
8. Does the Procedure document the review cadence (annual + event-trigger)?
9. Is there a populated Privacy Risk Register with at least the top-10 processing activities risk-assessed?
10. Does each risk-register entry record the principal-impact rating separately from the organisational-impact rating?
11. Does each risk-register entry record the affected PII principal class (with vulnerability flags for children, employees, persons with disability)?
12. Is there a DPIA / DPIP Register covering every triggered processing activity?
13. Does each DPIA follow the 29134 / Article 35(7) structure (systematic description, necessity and proportionality, principal-impact, mitigations, residual risk, consultation record)?
14. For Indian SDFs, is the DPIP done per DPDP section 10? Is the independent data audit done?
15. Is there a PIMS Statement of Applicability cross-walking every Annex A.1 / A.2 / A.3 control?
16. Does the SoA document the applicability status, the justification, the implementation state (current-state, evidenced) and the exclusion reasoning per control?
17. Are there controls marked applicable where the implementation is planned but not yet in operation? Red flag: yes (current-state discipline failure).
18. Are there controls marked not-applicable without a documented justification? Red flag: yes (exclusion-reasoning failure).
19. Is there a Risk Treatment Plan recording the treatment option, the controls selected, the implementation owner, the target date, the resource estimate and the residual-risk projection per material risk?
20. Is there a Risk-Acceptance Log with signed acceptance records for risks above the acceptance threshold?
21. Does each risk-acceptance record include the rationale, the conditions, the review date and the named risk owner's sign-off?
22. Is the register reconciled with the ROPA (Clause 8.2)? Each in-scope processing activity should have a corresponding risk-register entry.
23. Is the register reconciled with the requirements register (Clause 4.2)? Each material requirement should have a corresponding candidate-risk entry.
24. Is the register wired into the management review (Clause 9.3)? Is the residual-risk trajectory reported?
25. Has an event-trigger review happened since the last calendar review? (e.g., a new processing activity, a new sub-processor, a new regulation, a post-incident).
26. Is there a change-monitoring log capturing material changes between formal reviews?
27. Is the integrated-with-distinction posture evidenced? The DPO and the CISO co-author the methodology; the register has the principal-impact and organisational-impact columns populated for every privacy-relevant risk; the SoA covers both Annex A and ISO/IEC 27002:2022.
28. Is the privacy-risk methodology competence addressed under Clause 7.2 (DPO, CISO, process owners trained)?

Evidence the auditor will physically request

• The dated and signed Privacy Risk Assessment Procedure.
• The Privacy Risk Register (with the principal-impact column populated).
• The DPIA / DPIP Register (with each DPIA following the 29134 / Article 35(7) structure).
• The PIMS Statement of Applicability (covering all Annex A.1 / A.2 / A.3 controls).
• The Risk Treatment Plan.
• The Risk-Acceptance Log (with signed records).
• The management-review minutes showing the risk-register input.
• The change-monitoring log showing triggers fired since the last review and the resulting updates.
• The Documented Information control record (version history, approval workflow).
• Sample reconciliations: the risk-register entry for one sampled processing activity cross-referenced to the matching DPIA, the matching ROPA entry, the matching requirements-register entry, and the matching SoA control.
• The integrated-with-distinction evidence: the joint DPO + CISO methodology authorship; the shared register; the unified SoA.
• The DPO and CISO competence records (training, certification).
• The SDF-specific evidence (where applicable): the DPO appointment letter; the independent data audit report; the algorithmic-fairness review report.

Common Stage-1 nonconformities the auditor will write up

• NC pattern 1: Privacy Risk Assessment Procedure exists but principal-impact axis missing. Major NC. Remediation: methodology refresh with the principal-impact scale, 4 to 8 weeks.
• NC pattern 2: Reskin pattern (privacy register is infosec register with a label). Major NC. Remediation: integrated-with-distinction migration, 8 to 14 weeks.
• NC pattern 3: DPIA missing for a triggered processing activity. Major NC. Remediation: trigger-test refresh + DPIA pipeline, 4 to 12 weeks depending on the DPIA count.
• NC pattern 4: SoA documents future-state controls. Minor or major NC depending on extent. Remediation: current-state SoA refresh, 2 to 4 weeks.
• NC pattern 5: Exclusion reasoning absent on not-applicable controls. Minor NC. Remediation: exclusion-reasoning discipline, 2 to 4 weeks.
• NC pattern 6: Risk-Acceptance Log missing or unsigned. Major NC. Remediation: per-risk acceptance sign-off, 2 to 6 weeks.
• NC pattern 7: Risk register not reconciled with ROPA / requirements register. Minor or major NC depending on extent. Remediation: reconciliation workshop, 2 to 4 weeks.

Metrics and KPIs

1. Risk-register currency, percentage of risks reviewed within the last 12 months. Target: 100%.
2. Principal-impact rating coverage, percentage of risk-register entries with the principal-impact rating populated. Target: 100%. Red flag: below 100% indicates reskin-pattern risk.
3. DPIA trigger-test coverage, percentage of in-scope processing activities with the trigger test run. Target: 100%.
4. DPIA completion rate, percentage of triggered DPIAs completed within the target SLA. Target: 100% within 90 days of trigger.
5. SoA current-state discipline, percentage of applicable controls with current-state (not future-state) implementation evidence. Target: 100%.
6. SoA exclusion-reasoning coverage, percentage of not-applicable controls with documented exclusion reasoning. Target: 100%.
7. Risk-treatment-plan implementation rate, percentage of treatment-plan items implemented by the target date. Target: above 90%.
8. Residual-risk trajectory, quarter-on-quarter change in the count of high and critical residual risks. Target: downward trend.
9. Risk-acceptance record coverage, percentage of risks above the acceptance threshold with a signed acceptance record. Target: 100%.
10. Open risk-acceptance record count, the count of risks currently accepted above the threshold. Target: downward trend; spikes investigated at the management review.
11. Event-trigger review latency, median time from trigger event to register update. Target: under 15 days.
12. Integrated-with-distinction evidence, binary; the DPO and CISO co-author the methodology; the register has the dual-impact columns populated. Target: yes.
13. Risk-register-to-ROPA reconciliation, percentage of in-scope processing activities with a corresponding risk-register entry. Target: 100%.
14. SDF DPIP cadence, for SDFs, percentage of new processing activities with a DPIP completed before launch. Target: 100%.
15. Stage-1 audit nonconformities on 6.1, count. Target: zero.

Common Pitfalls and Audit Failures

Pitfall 1, The reskin. The privacy risk assessment is the infosec risk assessment with a privacy label. The principal-impact axis is missing; the DPIA triggers are not tested; the A.1 / A.2 control surface is invisible. The single most common 6.1 finding. Treatment: integrated-with-distinction migration (Move 1, Pattern A).

Pitfall 2, The principal-impact omission. The register exists but the principal-impact column is blank or populated with the organisational-impact rating. Treatment: principal-impact scale (Section 10.2) workshop; column population for every entry.

Pitfall 3, The DPIA gap. The trigger test has never been run; DPIAs are missing for triggered processing activities. Treatment: trigger-test refresh (Move 5); DPIA pipeline.

Pitfall 4, The future-state SoA. The SoA documents controls as applicable where the implementation is planned but not yet in operation. The certification auditor will write a nonconformity. Treatment: current-state SoA discipline.

Pitfall 5, The hypothetical-applicability SoA. Controls marked applicable on a hypothetical future relationship (the joint-controller control marked applicable because \"we may have a JV next year\", flagged in tier-1 practitioner commentary). Treatment: current-state applicability; future relationships in the opportunity axis.

Pitfall 6, The exclusion-reasoning gap. Controls marked not-applicable without a documented justification. Treatment: exclusion-reasoning discipline.

Pitfall 7, The unsigned risk-acceptance. Risks above the acceptance threshold retained without the named risk owner's sign-off. Treatment: risk-acceptance log discipline (Section 10.5).

Pitfall 8, The integrated-with-distinction failure (Pattern C). Two parallel registers that never reconcile. The two SoAs disagree on the same control. Treatment: reconciliation workshop; migration to Pattern A.

Pitfall 9, The annual-only review. The register is updated only in the 30 days before the surveillance audit, with the rest of the year dark. Treatment: event-trigger review mechanism; continuous monitoring.

Pitfall 10, The DPO-only workshop. The risk-assessment workshop is convened with only the DPO and a junior analyst in the room. Misses the CISO, the Legal, and the business-process owner inputs. Treatment: cross-functional workshop with sponsor attendance.

Pitfall 11, The risk-owner vacuum. The register lists risks but no named risk owner per risk. Treatment: risk-owner assignment following the processing-activity ownership.

Pitfall 12, The requirement-blind register. The register is built without reference to the Clause 4.2 requirements register. Non-compliance with a requirement is the canonical privacy risk; the register must reference the requirements. Treatment: requirement-to-risk bridge (toolkit doc 03).

Pitfall 13, The ROPA-blind register. The register is built without reference to the Clause 8.2 ROPA. Risks are identified in the abstract, not anchored to processing activities. Treatment: processing-activity-centric identification (Move 4).

Pitfall 14, The qualitative-without-criteria. The register uses qualitative ratings (low / medium / high) without documented risk criteria. The auditor cannot test the rating discipline. Treatment: documented risk criteria (Procedure Section 5).

Pitfall 15, The DPIA-without-necessity-and-proportionality. The DPIA exists but the necessity and proportionality test is missing or superficial. Treatment: necessity-and-proportionality workshop; the 29134 structure enforced.

Pitfall 16, The DPIA-without-consultation. The DPIA concludes residual-high but the DPBI / supervisory authority consultation is missing. Treatment: Article 36 prior-consultation process; DPBI engagement protocol.

Pitfall 17, The SDF-oblivion. The organisation crosses the SDF threshold (DPDP section 10) without realising it; the DPIP and the independent audit are not done. Treatment: SDF-designation analysis in the annual review.

Pitfall 18, The algorithmic-fairness gap. AI-driven processing activities without the algorithmic-fairness review. Section 10 exposure for SDFs; reputational risk for all. Treatment: algorithmic-fairness review pipeline.

Pitfall 19, The cross-border-blind register. The register does not surface the section 16 / GDPR Chapter V cross-border risks. Treatment: cross-border transfer risk theme in the workshop.

Pitfall 20, The children's-data assumption. The organisation assumes no children's-data exposure (B2B, enterprise SaaS) but the marketing-lead data, the HR data, or the customer-support tool includes minors. Treatment: section 9 exposure tested across all processing activities.

Pitfall 21, The dual-clock blindness. The breach playbook handles the DPDP 72-hour clock but not the CERT-In 6-hour clock (or vice versa). Treatment: dual-clock pattern in the breach playbook (Clause 8).

Pitfall 22, The treatment-without-implementation. The treatment plan selects the modify option with specific controls, but the controls are not actually implemented in the operational processes. Treatment: implementation discipline; evidence in the SoA.

Pitfall 23, The SoA-without-evidence. The SoA marks controls applicable but does not reference the implementation evidence. Treatment: evidence column population per control.

Pitfall 24, The methodology-without-competence. The Procedure exists but the DPO, the CISO and the process owners are not trained on it. Treatment: training programme under Clause 7.2.

Pitfall 25, The board-invisible register. The risk register and the residual-risk trajectory are not reported to the board / Risk Management Committee (for listed entities and SDFs). Treatment: board-on-a-page summary every cycle.

Illustrative Scenario 1: Failure, Indra Health with a Missing Principal-Impact Axis (Illustrative)

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative scenario. Indra Health is a fictional Bengaluru-based healthtech platform offering telemedicine, diagnostics booking and chronic-care management; the facts are composite from publicly reported sector patterns and should not be attributed to any real organisation.

Indra Health built its PIMS in 2024, ahead of an ISO/IEC 27701:2019 certification push. The risk assessment was a reskin of the existing ISO/IEC 27001:2022 ISMS risk register: the same asset-threat-vulnerability matrix, the same business-impact ratings (operational disruption, regulatory fine, reputational damage), with a single column \"PII\" added to mark which assets held personal data. The risk register had 67 entries; the SoA marked every Annex A control applicable with a justification of \"protects PII\"; the DPIA register had one entry, completed superficially for the telemedicine video-consultation feature.

Between 2024 and 2026 the regulatory landscape shifted materially. The DPDP Rules 2025 (notified 13 November 2025) operationalised the section 10 SDF regime; Indra Health crossed the SDF threshold (approximately 2.3 million patient records) without realising it. The DPIP obligation under section 10 was not triggered in the register; the independent data audit was not commissioned; the algorithmic-fairness review on the chronic-care-management recommendation engine was not done.

In March 2026 a published investigation alleged that the chronic-care-management engine was systematically deprioritising older patients for a particular chronic-care programme, with a measurable adverse outcome on the deprioritised cohort. The principal-impact was severe on the non-discrimination and safety dimensions. The DPBI preliminary inquiry (under section 18) identified the defective risk assessment as the root cause, the PIMS was designed without the principal-impact axis, and the algorithmic-fairness risk was invisible in the register.

The certification body issued a major nonconformity on Clause 6.1 at the next surveillance audit, cascading into nonconformities on 5.2 (policy), 5.3 (the algorithmic-fairness reviewer role absent), 6.2 (no objective on algorithmic fairness), 7.2 (no competence on algorithmic-fairness review), 8.2 (the operational risk assessment also missing the principal-impact axis), Annex A.1.2.5 (the DPIA was superficial), A.1.4.x (privacy by design did not address the algorithmic-fairness dimension), and A.1.3.11 (automated decision-making, the principal's right to contest was not operationalised). The certificate was suspended pending remediation.

The remediation re-engineered the entire risk methodology (integrated-with-distinction posture with the principal-impact axis), re-ran the DPIA pipeline for 23 processing activities, established the algorithmic-fairness review pipeline, and re-built the SoA with current-state evidence.

The lessons: a reskin-pattern risk assessment fails the audit and the regulator because the principal-impact axis is invisible; the DPDP section 10 SDF designation is a real risk that the register must surface; the algorithmic-fairness review is not optional for AI-driven processing activities; a SoA that marks every control applicable with a generic justification is decoration.

Illustrative Scenario 2: Success, Tarini Fintech Integrated Privacy-Risk Re-design (Illustrative, with ROI)

Illustrative scenario. Tarini Fintech is a fictional Mumbai-based digital-lending platform with 1,800 staff and a Payment Aggregator licence; the facts are composite from publicly reported sector patterns and should not be attributed to any real organisation.

Tarini Fintech ran an integrated ISO/IEC 27001:2022 + ISO/IEC 27701:2019 programme with a single risk register inherited from the ISMS. The principal-impact axis was missing; the DPIA register had two entries (the credit-scoring engine, the cross-border analytics flow) at the 2019 standard's lighter depth. The SoA marked every Annex A control applicable with one-line justifications.

In Q4 2025 the DPO commissioned a 6.1 refresh ahead of the 27701:2025 transition. The workshop surfaced six material shifts. First, the pattern was reskin (Pattern C); the DPO and the CISO had been operating in functional silos. The decision was to migrate to Pattern A (integrated-with-distinction). Second, the DPIA trigger test had not been re-run with the Article 35 / WP248 criteria on the post-2025 processing activities (the BNDF partner-bank integration, the AI-driven credit-scoring upgrade, the marketing-lead scoring, the collections-call recording archive). Seven processing activities triggered; the existing two DPIAs were re-done to the 29134 / Article 35(7) depth. Third, the SDF designation analysis had not been done; Tarini was approaching the threshold; the analysis was completed and Tarini was designated six months later, with the obligations already in operation. Fourth, the principal-impact axis was missing; the scale was populated for every entry; 14 risks were re-rated upward. Fifth, the SoA was future-state; 11 controls were marked applicable where the implementation was planned but not yet in operation; the SoA was re-built with the current-state discipline. Sixth, the risk-acceptance log was missing; three risks above the threshold had been retained without sign-off; the log was established and the risk owners signed.

Tarini rebuilt the artefact set: a 38-page Privacy Risk Assessment Procedure (Pattern A documented), a 142-entry Privacy Risk Register (with principal-impact populated), a 7-entry DPIA / DPIP Register (with one DPBI consultation record on the credit-scoring engine residual-high), a 78-control PIMS SoA (52 applicable current-state; 26 not-applicable with documented exclusions), a 47-item Risk Treatment Plan, and a 4-entry Risk-Acceptance Log.

The ROI: the integrated-with-distinction posture saved an estimated 18 lakh rupees per year in avoided parallel-pattern reconciliation overhead; the DPIA pipeline on the credit-scoring engine identified the algorithmic-bias risk early enough to remediate before the public-launch exposure (an estimated 8 crore rupees in avoided DPDP section 10 penalty exposure and brand damage); the current-state SoA discipline surfaced 11 controls that were marked applicable but not actually in operation, closing that gap before the surveillance audit avoided an estimated 4 to 8 weeks of timeline slippage and 1.5 to 3 lakh rupees in extra auditor fees; the SDF designation analysis positioned Tarini to be designation-ready without scrambling. Annualised saving: approximately 22 lakh rupees in direct cost avoidance plus the risk-adjusted 8 crore rupees in avoided penalty / brand damage exposure. Payback: under 18 months on the direct saving alone; under 3 months on the risk-adjusted basis.

The lessons: the integrated-with-distinction posture is the highest-use Pattern decision for most Indian growing companies; the DPIA pipeline is a regulatory and commercial hedge, not a compliance overhead; the current-state SoA discipline is cheap insurance against a Stage 1 finding; the SDF designation analysis must be on the annual-review agenda.

Multi-Framework Mapping

The densest cross-framework mappings are at the principal-impact row (GDPR Art 35(1); DPDP s.10; NIST PF Identify-P; ISO/IEC 27557), the DPIA-structure row (GDPR Art 35(7); DPDP s.10; ISO/IEC 29134), and the SoA row (GDPR Art 5(2) accountability; DPDP s.8(5); ISO/IEC 27001:2022 Clause 6.1.3). These three rows carry most of the cross-framework credibility of a 6.1 guide.

The unique-to-India row is the SDF DPIP / independent audit / algorithmic-fairness review (DPDP section 10), no direct GDPR analogue exists at the SDF designation level; the GDPR large-scale + special-category triggers operate differently. The Indian SDF regime is a distinctive construct that the 6.1 guide must address head-on.

Implementation Roadmap

30 days

• Decide the pattern (Move 1, Pattern A integrated-with-distinction is the recommended default).
• Stand up the workshop (Move 2); identify the workshop attendees (DPO, CISO, Legal, top-10 processing-activity owners) and the date.
• Issue the workshop pre-read (current risk register if any; current SoA; the ROPA from Clause 8; the top 10 customer DPAs; the top 10 processor agreements; the requirements register from 4.2).
• Begin the threat-intelligence subscription trial.
• Refresh the Procedure (Move 3), or write it from scratch using the Singahi toolkit doc 02 template.

90 days

• Complete Move 4, populate the Privacy Risk Register for the top 10 processing activities, with the principal-impact and organisational-impact axes populated.
• Complete Move 5, run the DPIA trigger test for every in-scope processing activity; commission the DPIAs for the triggered activities.
• Build the SoA draft (Move 6) with the current-state discipline and the exclusion-reasoning discipline.
• Run the SDF designation analysis (DPDP section 10).
• Build the Risk-Acceptance Log; secure the sign-offs for the risks above the threshold.

180 days

• Run the first event-trigger review (if no trigger has fired, simulate one, e.g., a new processing activity, a new sub-processor, a new regulation).
• Wire the risk-monitoring mechanism into the DPO's and the CISO's monthly cycle.
• Present the residual-risk trajectory to the board / Risk Management Committee (for SDFs and listed entities).
• Update the awareness programme to reference the material risks (Clause 7.3) and the training programme on the methodology (Clause 7.2).

12 months

• Run the first full annual review at the management review.
• Update the risk register to reconcile with the full ROPA and the full requirements register.
• Run an internal-audit test against the Section 11 checklist (Clause 9.2).
• Calibrate the metrics against the Section 12 targets.
• Reassess the SDF designation analysis in light of the data-volume growth.
• For SDFs, commission the independent data audit and the algorithmic-fairness review per the section 10 cadence.

FAQ

Q1. We already have an ISO/IEC 27001:2022 Clause 6.1 infosec risk register. Can we reuse it for 27701?

Yes, with the integrated-with-distinction migration (Pattern A). The infosec register covers the security-relevant risks; the PIMS register adds the privacy-specific load, the principal-impact axis, the DPIA / DPIP trigger test, the Annex A.1 / A.2 / A.3 control surface. Most Indian growing companies run a single combined register with two clearly labelled impact columns and two clearly labelled control surfaces.

Q2. Our risk register is in a spreadsheet. Is that enough?

A spreadsheet is acceptable for the first cycle. The test is whether the methodology is documented, the principal-impact axis is populated, the DPIA pipeline is operational, and the SoA is current-state. A spreadsheet that does all of that outperforms a GRC platform that does none of those things.

Q3. We are not yet designated an SDF. Do we need to do the DPIP under DPDP section 10?

The DPIP obligation applies to Significant Data Fiduciaries. The designation is by the Central Government on prescribed thresholds. The discipline is to run the SDF-designation analysis annually (data volume, sensitivity, risk to principals, sovereignty impact); if the thresholds are approachable, build the DPIP / independent-audit / algorithmic-fairness-review operating model ahead of the designation. The ISO/IEC 27701:2025 risk methodology is the natural single framework that satisfies both the PIMS obligation and (when designated) the section 10 obligations.

Q4. How is the principal-impact rating different from the organisational-impact rating?

The principal-impact measures the severity of the harm to the PII principal (autonomy, dignity, financial standing, safety, non-discrimination, rights). The organisational-impact measures the severity of the harm to the organisation (operational disruption, regulatory penalty, contractual breach, reputational damage). The two ratings can diverge, a small breach of sensitive children's data may have a severe principal-impact and a low organisational-impact; a large breach of low-sensitivity marketing-lead data may have a moderate principal-impact and a high organisational-impact. The 2025 edition expects both ratings to be recorded separately.

Q5. How many DPIAs do we need to do?

The trigger test decides. For most growing companies the DPIA register covers 3 to 10 processing activities. For mid-market and enterprise, 10 to 30 and 30 to 500+ respectively. SDFs typically have a fuller DPIA register because the section 10 obligation applies to every new processing activity. The Singahi trigger test decision tree (toolkit doc 02 Section 6) operationalises the DPDP + GDPR + ISO/IEC 29134 triggers in a single test.

Q6. What happens if the DPIA concludes residual-high risk?

Under GDPR Article 36 the controller must consult the supervisory authority before processing. Under DPDP section 10 the SDF engages the Data Protection Board of India on the DPIP outcome. The consultation record is part of the DPIA. The 2025 edition expects the consultation pathway to be documented in the methodology; residual-high risk is not a stop sign, but it is a flag for prior consultation and for the risk owner's formal acceptance.

Q7. Our SoA has controls marked applicable that we plan to implement next year. Is that a problem?

Yes. The SoA reflects the current operational reality on the audit day. A control marked applicable where the implementation is planned but not yet in operation is a nonconformity. The planned controls belong in the Risk Treatment Plan, not in the SoA. The SoA can include a separate \"planned controls\" annex for transparency, but the applicability column reflects the current state.

Q8. We marked a control not-applicable because we don't currently have a joint-controller relationship, but we may have one next year. Is that OK?

Yes, not-applicable with documented exclusion reasoning is the correct answer. The control is marked applicable only when the joint-controller relationship exists. Tier-1 practitioner commentary flags the \"hypothetical future relationship\" as a common NC; the SoA reflects the current state, not the future intention.

Q9. Our risk-acceptance log is signed by the DPO. Is that enough?

It depends. The risk owner is the named individual accountable for the risk, typically the business-process owner for the processing activity that generates the risk, not the DPO. The DPO maintains the log; the risk owner signs the acceptance. For risks above the risk-appetite threshold, the top management may need to sign (Clause 5.1 leadership responsibility).

Q10. Can we use the FAIR quantitative methodology?

Yes, but the methodology must be documented, defensible, and competence-supported. For most growing companies a well-documented qualitative methodology with documented risk criteria outperforms a poorly-supported quantitative one. Quantitative methods (FAIR, Monte Carlo) are maturity-upgrade territory, not a first-cycle requirement.

Q11. How is 6.1 different from 8.2 (the operational privacy risk assessment)?

6.1 is the planning-layer risk methodology, the framework, the criteria, the treatment-option taxonomy, the SoA, the risk-acceptance discipline. 8.2 is the operational-layer risk assessment, the per-processing-activity risk evaluation that lives in the ROPA-type records. The 6.1 methodology produces the framework; the 8.2 assessment applies it. The two are complementary; the 6.1 methodology must be designed to produce a defensible 8.2 output.

Q12. Do we need to do algorithmic-fairness review on every AI-driven processing activity?

For SDFs under DPDP section 10, yes. For non-SDFs, the algorithmic-fairness review is recommended (not mandatory under DPDP) but the GDPR Article 22 ADM risk and the WP248 \"evaluation or scoring\" + \"automated decision-making\" criteria together make the review effectively mandatory where those criteria fire. The Singahi trigger test (toolkit doc 02 Section 6) flags the algorithmic-fairness dimension where the AI-driven criterion fires.

Q13. Our breach playbook handles the DPDP 72-hour clock. Is that enough?

No. A personal-data breach triggers two parallel clocks in India: the CERT-In 6-hour clock (CERT-In Directions 28 April 2022, the ICT-incident angle) and the DPDP 72-hour clock (DPDP Act section 8(6) read with DPDP Rules 2025 Rule 7, the personal-data angle). For BFSI and listed entities, a third clock applies (RBI six hours; SEBI 6 hours; IRDAI 24 to 72 hours). The breach playbook must handle all applicable clocks in parallel from the same awareness event.

Q14. Can we outsource the risk assessment entirely?

The artefact construction can be outsourced (with external advisory); the identification of the risks cannot be outsourced because it requires organisational knowledge of the processing activities. The DPO owns the artefact; the workshop attendees (the business-process owners) own the input.

Q15. How often should we re-run the DPIA?

The DPIA is re-run on material change to the processing activity (new data types, new purposes, new sub-processors, new geography, new technology) and at least annually as part of the management-review cycle. The DPIA register records the review date per entry.

Industry-Specific Requirements

BFSI

Banks, NBFCs, payment aggregators, payment gateways, insurers. The BFSI risk register carries the heaviest regulatory load: the DPDP section 8(5) safeguards, the section 8(6) breach notification (72-hour clock), the section 10 SDF obligations (most large BFSI players are likely SDFs), the RBI Storage of Payment System Data directive (6 April 2018), the RBI Digital Lending Guidelines (2 September 2022, borrower-consent, device-data minimisation, privacy-by-design for lending apps), the RBI Tokenisation circular (22 September 2021), the RBI Cybersecurity Directions 2026 (31 July 2026; incident reporting within six hours), the SEBI CSCRF (20 August 2024), the IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023). The risk register must surface the dual-clock pattern (CERT-In 6 hours, DPDP 72 hours, RBI and SEBI six hours, IRDAI per its own guidelines) and the BFSI-specific harm scenarios (financial fraud, identity theft, credit-discrimination). The DPIA register typically covers 30 to 100 processing activities for a mid-sized BFSI player; the algorithmic-fairness review is critical for credit-scoring, fraud-detection and collections engines.

Healthcare

Hospitals, telemedicine platforms, healthtech, insurers processing health data. The risk register must flag the heightened sensitivity of health data (the DPDP section 9 analog for vulnerable data subjects; the SPDI Rules' explicit inclusion of health data; clinical-data-confidentiality expectations; the IRDAI framework where insurance is involved). The DPIA threshold is low, most material processing activities require DPIA treatment. The principal-impact \"safety\" dimension is load-bearing for clinical-data risks. The role declaration is complex, hospitals are controllers for patient data, processors for some insurance-claim data, joint controllers with referring physicians in some cases. The DPIA pipeline must cover the AI-driven diagnostic engines, the telemedicine video-consultation features, the chronic-care management engines, the cross-border second-opinion flows.

IT-ITeS and SaaS

IT services firms, BPOs, SaaS providers, cloud processors. The risk register is almost always \"both\", the customer's principals reached through the organisation's processing (processor-side risks: infringing-instruction, sub-processor management, breach-notification-to-controller), and the organisation's own employees, marketing-lead contacts and beta-test users (controller-side risks). The cross-border transfer issue is central, most ITeS firms process data of overseas principals under GDPR/CCPA jurisdiction; the DPIA trigger fires frequently (WP248 \"data processed on a large scale\" + \"data transfer outside the EU\" + \"systematic monitoring\"). The standalone-PIMS scoping decision lets SaaS firms scope a PIMS to the customer-data plane only, separate from the ISMS-scoped engineering plane.

E-commerce and Retail

D2C brands, marketplaces, e-commerce platforms, omni-channel retailers. The risk register must address consumer-privacy expectations at scale, the children's-data regime where minors are in the user base, the marketing-lead consent regime, the supplier-ecosystem processor chains, the payment-data overlays (RBI Tokenisation, the Payment Aggregator obligations). The DPIA register typically covers the recommendation engine, the marketing-lead scoring, the cross-border analytics, the loyalty programme (often a joint-controller arrangement under Annex A.1.2.8). The Consent Manager integration (DPDP section 2(1)(g)) is particularly relevant for consumer-facing firms; the consent-quality risk (consent not as-easy-to-withdraw) is a frequent finding.

Edtech

K-12 platforms, higher-edtech, skilling platforms, test-prep. The children's-data regime (DPDP section 9) is the central risk-register issue, the principal is a minor, the consent dynamic is parental, and the section 9 verifiable-parental-consent + no-behavioural-monitoring-or-targeted-advertising regime is load-bearing. The DPIA threshold is low, most material processing activities require DPIA treatment. The DPIA pipeline must cover the recommendation engine (the behavioural-monitoring risk under section 9), the marketing-lead scoring, the AI-driven adaptive-learning features, the cross-border data flows (where overseas curricula or overseas student populations are involved). The principal-impact \"safety\" and \"dignity\" dimensions are load-bearing for minor-principal risks.

Manufacturing

Discrete and process manufacturing, automotive, chemicals, pharma manufacturing. The risk register must address the OT-IT convergence (operational technology systems increasingly connected, with PII exposure in HR, contractor and visitor data), the supply-chain processor ecosystem, the geopolitical context for cross-border manufacturing data flows. The principal set includes employees, contractors, visitors, customers (where the manufacturer operates a direct-to-customer channel), and patients (for pharma manufacturing with patient-level pharmacovigilance data). The DPIA register typically covers the employee-monitoring tools (OT-IT convergence), the contractor-management systems, the pharmacovigilance reporting (for pharma). The role declaration is typically simpler than in consumer-facing sectors.

Cross-sector patterns

Three patterns recur across sectors and are worth flagging in any 6.1 register regardless of industry.

The processor-side scale pattern. Indian ITeS, BPO, SaaS and cloud-processor firms typically process personal data at volumes that easily cross the DPDP SDF thresholds even though their consumer brand is small. The principal-as-affected-population runs into millions; the SDF-designation analysis must use the volume of data processed (not the headcount) as the threshold proxy.

The dual-regulator pattern. BFSI and listed entities carry dual-regulator exposure, DPDP via the Data Protection Board plus the sector regulator (RBI, SEBI, IRDAI). The risk register must capture both regulatory streams and the dual-clock pattern they create (CERT-In 6 hours, DPDP 72 hours, sector six hours).

The AI-driven profiling pattern. AI-driven processing activities (credit-scoring, marketing-lead scoring, recommendation engines, fraud detection, adaptive learning, algorithmic hiring) trigger multiple DPIA criteria (WP248 \"evaluation or scoring\" + \"automated decision-making\" + \"innovative use\") and require the algorithmic-fairness review regardless of sector. The 6.1 register must surface these activities explicitly and the DPIA pipeline must cover them.

Maturity Model

Emerging Trends

AI-driven processing and the algorithmic-fairness axis. The DPDP section 10 SDF algorithmic-fairness review, the 2025 edition's callout of AI-driven profiling and automated decision-making, and the parallel development of ISO/IEC 42001:2023 (AI Management System) are reshaping the 6.1 risk landscape. For organisations using AI/ML on personal data, the algorithmic-fairness risk is the highest-use principal-impact axis addition; the DPIA pipeline must include the algorithmic-fairness review for every AI-driven processing activity.

DPDP SDF designations and the DPIP cadence. The Central Government is expected to designate the first wave of SDFs through 2026 and 2027 as the DPDP Rules 2025 phased commencement completes. Designated SDFs must operationalise the DPIP / independent-data-audit / algorithmic-fairness-review cadence under section 10. The 6.1 methodology is the natural framework for the DPIP; the ISO/IEC 27701:2025 PIMS is the natural single system that satisfies both the management-system obligation and the section 10 obligations.

DPBI operational emergence. The Data Protection Board of India, constituted under DPDP section 18, is emerging through 2026 and 2027. Its early orders, its interpretation of the Schedule penalty maxima, its engagement patterns on DPIA consultations (GDPR Article 36 analogue), and its precedent on the breach-notification clock will reshape the 6.1 risk landscape for every Indian Data Fiduciary.

Cross-border transfer regime evolution. The DPDP negative list under section 16, the EU–US Data Privacy Framework adequacy decision (10 July 2023), the UK IDTA / Addendum, the China PIPL cross-border mechanisms (the CAC security assessment, the CAC standard contract, certification), and the geopolitical risk environment are all in flux. The 6.1 register must monitor this dimension continuously; the cross-border transfer risk theme is dynamic.

Consent Manager ecosystem emergence. The DPDP Rules 2025 prescribe Consent Manager registration conditions; the first Consent Managers are expected to be registered through 2026 and 2027. As the ecosystem emerges, the Consent Manager integration becomes a risk-treatment option for consent-quality risks; the consent-withdrawal-signal honouring is operationalised through the Consent Manager interface.

Integrated management systems. The harmonized structure enables integrated 27001 + 27701 + 42001 + 22301 governance. The risk methodology is the natural point of integration, a single combined methodology that serves all four management systems with clearly labelled sub-sections. The integrated-with-distinction posture (Pattern A) is the foundation.

Quantum and post-quantum cryptography horizon. The post-quantum-cryptography transition (NIST PQC standards, ISO/IEC 18033, ISO/IEC 20889) is a long-horizon risk-register entry, the principal's long-retention personal data may need re-encryption, and the regulator may impose PQC-readiness expectations. The 6.1 register should monitor this dimension.

Generative AI in PIMS operations themselves. The use of generative AI inside the PIMS function (for DPIA drafting support, ROPA automation, breach-notification drafting) is a 6.1 risk in its own right, the principal-impact axis must consider the generative-AI-specific harm scenarios (training-data leakage, prompt-injection-driven disclosure, model hallucination on principal-rights requests). The 2025 edition's callout of AI-driven profiling applies to internal use as much as to customer-facing use.

Privacy by design as default market expectation. Beyond the regulatory overlay, customer expectations (especially enterprise customers running their own privacy programmes) are driving privacy-by-design into the procurement requirements. The 6.1 register must capture the market-driven privacy demands alongside the regulatory ones, the customer DPA is increasingly the strictest source of risk treatment.

Sector-regulator convergence on privacy risk. RBI, SEBI and IRDAI are each tightening their privacy-adjacent rules (RBI Digital Lending, SEBI CSCRF, IRDAI ICS 2023). The DPDP Act sits as a horizontal layer above these sectoral instruments; the 6.1 register must monitor both the horizontal and the sectoral streams because they can diverge in their specific obligations even when they share the underlying privacy principle.

Climate-related privacy risks. The 2025 edition's climate-change amendment (to Clauses 4.1 and 4.2) intersects with 6.1, climate-driven disruption of PII processing (climate-exposed data centres, climate-driven supply-chain failures affecting processors, climate-driven migration affecting principal populations) is an emerging risk-register dimension for climate-exposed sectors.

References and Further Reading

Primary instruments (India). Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023, enacted 11 August 2023), MeitY, in particular sections 8(5), 8(6), 9, 10 (SDF, DPO, DPIP, independent data audit, algorithmic-AI fairness review), 11–14, 16, 18, 33 + Schedule (penalty maxima up to 250 crore for s.8(5) failure; 150 crore for ss.8(6) and 9; 150 crore for s.10). Digital Personal Data Protection Rules, 2025 (notified 13 November 2025), MeitY, Rule 7 (the 72-hour breach clock and format); SDF thresholds; Consent Manager registration. Information Technology Act, 2000, sections 43A, 72A, 70B. IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (notified 11 April 2011). CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), the 6-hour clock. RBI Storage of Payment System Data (6 April 2018); RBI Digital Lending Guidelines (2 September 2022); RBI Tokenisation (22 September 2021); RBI Cybersecurity Directions 2026 (31 July 2026). SEBI Cybersecurity and Cyber Resilience Framework (20 August 2024). IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023). Companies Act 2013, sections 134(3)(n), 177; SEBI LODR Regulation 21.

Primary jurisprudence (India). K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (nine-judge Bench, 24 August 2017). Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 (five-judge Bench, 26 September 2018).

Primary instruments (global). Regulation (EU) 2016/679 (GDPR), OJ L 119, 4.5.2016, p. 1; application from 25 May 2018, Articles 5(2), 24, 32, 35 (DPIA), 35(1) (the \"high risk to the rights and freedoms\" trigger), 35(7) (DPIA content), 36 (prior consultation). Article 29 Working Party, WP248 rev.01 (the nine-criteria DPIA-trigger list). EDPB Guidelines 9/2022 on personal data breach notification. CJEU, Schrems II, C-311/18, 16 July 2020 (the transfer-impact-assessment duty). European Commission Implementing Decision (EU) 2021/914 (modernised SCCs). EU–US Data Privacy Framework adequacy decision (10 July 2023). NIST Privacy Framework v1.0, NIST.CSWP.01162020, 16 January 2020, the Identify-P function. NIST SP 800-37 Rev. 2 (Risk Management Framework). AICPA, 2017 Trust Services Criteria (with 2022 Points of Focus update), CC3.1, CC3.2, CC3.3. Brazil LGPD, Lei nº 13.709/2018. China PIPL, Article 55 (mandatory PIA).

ISO/IEC standards. ISO/IEC 27701:2025 (2nd ed., published 14 October 2025), Clause 6.1 (6.1.1 General, 6.1.2 Privacy risk assessment, 6.1.3 Privacy risk treatment), Annex A.1.2.5 (PIA), Annex B (normative in 2025). ISO/IEC 27701:2019 (1st ed., for transition reference, Annex F.2.5 risk-assessment guidance). ISO/IEC 27001:2022 Clause 6.1 (infosec risk). ISO/IEC 27002:2022, only 5.34 is PII-specific. ISO/IEC 27005:2022 (infosec risk management). ISO/IEC 29134:2017 (DPIA guidelines). ISO/IEC 27557 (impact assessment). ISO 31000:2018 (risk management, the four-treatment-option source). ISO/IEC 29100:2011 (privacy framework, 11 principles). ISO/IEC 27018:2019 (cloud PII processor); ISO/IEC 27017:2015 (cloud security); ISO/IEC 29151 (PII protection code). ISO/IEC 42001:2023 (AI Management System, algorithmic-fairness review cross-reference). ISO/IEC 27706:2025 (PIMS cert-scheme competence). ISO/IEC 27001:2022 Amendment 1:2024 (climate-change addition to 4.1; mirrored in 27701:2025 for 4.1/4.2, intersects with 6.1).

Edition-transition sources (practitioner commentary used as research input). ANAB Heads Up #550 (transition timeline). The 2025 edition's structure, control counts (31 + 18 + 29 = 78 consensus; one tier-1 cert-body source reports an outlier count of 86 on a different counting basis), the principal-impact axis inheritance from 27701:2019 Annex F, the DPIA / DPIP trigger integration with DPDP section 10 and GDPR Article 35, the normative-Annex-B change, and the climate-change amendment are confirmed from the official 2025 PDF (OCR) and corroborated by tier-1 practitioner commentary. The common-nonconformity patterns (the integrated-versus-parallel risk-assessment zone; the SoA documents-future-state failure; the hypothetical-applicability failure; the missing principal-impact axis) are drawn from tier-1 cert-body practitioner commentary. All clause text in this guide is paraphrased; the official text is copyrighted by ISO/IEC and has not been reproduced.

Singahi references. The Singahi Clause 6.1 toolkit (17 docs + README) accompanies this guide. The Singahi 27701:2025 series covers all MSS clauses (4 to 10) and Annex A.1 / A.2 / A.3 controls; sibling guides for 4.1, 4.2, 4.3, 4.4, 5.x, 6.2, 6.3 and the rest of the standard are available.

This guide is published by Singahi. The ISO/IEC 27701:2025 clause text is copyrighted by ISO/IEC and has not been reproduced; all requirements are paraphrased. Brand names of competitors, cert bodies, and reference books are intentionally omitted. Scenarios are illustrative and should not be attributed to any real organisation.