ISO 27701 A.3: Technological Controls

Quick Reference (60 Seconds)

If you only read one thing: the A.3 Technological controls are where the PIMS stops being an abstract privacy discipline and becomes an engineering discipline. A controller can have a perfectly drafted privacy notice, a perfectly maintained ROPA, a perfectly trained workforce, and still lose a principal's data through an unencrypted backup tape, an over-broad production query that logs plaintext PII into the application log, a self-signed certificate on an internal PII-bearing API, a shared service-account password on the PII application, or a development vendor who pushes code with the production crypto keys embedded in the repository. The ten controls in this guide are the most engineering-heavy A.3 controls, they live in the tech stack, not in the policy library. Get them wrong and however strong the organisational, people and physical architecture, the PIMS is non-conformant, the DPDP section 8(5) safeguards duty is unmet, and the Data Protection Board of India, after a breach, will ask why the PII was not encrypted, why the access was not logged, why the key management was undisciplined, and why the development vendor was operating without privacy clauses.

What the Standard Actually Requires

The paraphrased family-level requirement

ISO/IEC 27701:2025 controls A.3.22, A.3.23, A.3.24, A.3.25, A.3.26, A.3.27, A.3.28, A.3.29 and A.3.30, together with the A.3 Technological-family controls aligned to ISO/IEC 27002:2022 theme 8, ask PII controllers and processors to extend their technological security discipline to the protection of personally identifiable information across the layers where PII lives: the endpoint device that opens a session on the PII database (A.3.22); the authentication that proves the user's identity to that session (A.3.23); the backup that preserves PII restorable across an outage or a ransomware event (A.3.24); the logging that records who accessed which PII when and from where (A.3.25); the cryptography that renders PII unreadable to unauthorised parties at rest, in transit and in use (A.3.26); the development life cycle that builds privacy into the application from requirements to retirement (A.3.27); the application security requirements that name PII explicitly in the engineering backlog (A.3.28); the secure system architecture and engineering pattern that protects PII by design across the stack (A.3.29); and the outsourced development discipline that extends these controls to vendors and sub-contractors who build systems that touch PII (A.3.30).

The family operates as a layered architecture: the endpoint layer (A.3.22) is the user's seat; the authentication layer (A.3.23) gates access to the PII; the crypto layer (A.3.26) makes the PII unreadable to anyone who reaches it without authorisation; the logging layer (A.3.25) records what happened; the backup layer (A.3.24) preserves restorability; the engineering layers (A.3.27 / A.3.28 / A.3.29) build the protection into every system that touches PII; and the outsourced layer (A.3.30) propagates the discipline to the vendor base. A controller or processor that holds the layers as one coherent engineering architecture will pass an A.3 Technological audit; one that treats each control as a disconnected IT duty will pass the paperwork but fail the operational test.

The lineage, 2019 to 2025

Under ISO/IEC 27701:2019, the security controls lived in clause 6, an extension of clauses 5 (the 27001 ISMS) and 7 (the 27002 control set). The 2019 structure required the organisation to hold a 27001 certificate (or at least a 27001-conformant ISMS) before 27701 could attach, which made the A.3-equivalent controls inherited from the underlying ISMS rather than implemented inside the PIMS itself. The 2025 edition consolidates the security controls into Annex A.3 as a normative annex of the standalone PIMS, aligned to ISO/IEC 27002:2022's four themes (5 Organisational / 6 People / 7 Physical / 8 Technological). A separate 27001 certificate is no longer a prerequisite, but the A.3 controls, including the Technological theme, must be implemented within the PIMS scope.

The 2025 edition's relationship to ISO/IEC 27002:2022 is explicit: Annex B has no B.3 section, and the implementation guidance for A.3 controls points directly to ISO/IEC 27002:2022. Auditors test the A.3 Technological controls against the 27002:2022 control statement (with the PII-protection overlay that 27701 brings via the broader PIMS), not against a 27701-specific restatement. The Singahi ISO/IEC 27001 / 27002 library is therefore the reference for the generic technological-security depth; this A.3 guide adds the privacy overlay that makes each technological control PIMS-relevant.

The Singahi library already covers the underlying ISO/IEC 27001:2022 Annex A.8 controls (technological security) and the ISO/IEC 27002:2022 theme 8 controls at full depth, the endpoint posture, the authentication architecture, the logging design, the cryptographic standards, the backup architecture, the secure-development life cycle, the application security testing, the secure system architecture, the outsourced-development contracts. This condensed guide does not re-build that depth. It cross-references the Singahi ISO/IEC 27001 library and focuses on the PII-protection overlay: where the PII lives, what makes the protection PII-aware, and how the dual-clock pattern engages when a technological control fails.

The privacy overlay, what makes an A.3 Technological control "PII-aware"

An A.3 Technological control is "PII-aware" when the underlying technological security control is implemented with a specific, documented dimension that addresses the protection of personal data. The privacy overlay is not optional in a PIMS scope, it is what distinguishes an A.3 Technological control from a generic 27002 theme-8 control. The ten controls' PII overlays are treated in full in Section 7 (control-by-control); the load-bearing headline: A.3.26 Use of cryptography is the technical expression of DPDP section 8(5) confidentiality, the encryption of PII at rest, in transit and (where supported) in use, plus the key-management lifecycle and the crypto-shredding pattern for end-of-life PII. The other eight controls carry overlays proportionate to their position in the stack (endpoint encryption for A.3.22; MFA on every PII session for A.3.23; encrypted backup with separate key for A.3.24; sanitised PII-access logging with 180-day retention for A.3.25; privacy-by-design in the SDLC for A.3.27 / A.3.28 / A.3.29; flow-down to vendors for A.3.30).

The architectural posture, technology as the privacy backstop for the digital layer

The A.3 Technological family is the privacy backstop for the digital slice of the PIMS. The relationship is asymmetric: a strong A.3 Technological implementation does not, by itself, make a strong PIMS (the privacy discipline lives in A.1 / A.2 and the MSS clauses, and the organisational, people and physical discipline lives in the other A.3 themes); but a weak A.3 Technological implementation undermines every privacy commitment that depends on a digital system. A controller that promises consent withdrawal (A.1.3.5) but cannot locate and purge the principal's PII from the cached non-production copy has a privacy commitment the tech layer cannot honour. A processor that promises to process only on instructions (A.2.2.x) but allows its engineers to use a shared service-account password on the customer-controller's PII database has a privacy commitment the tech layer cannot honour. A controller that promises secure retention (A.1.4.8) but ships unencrypted backup tapes to a third-party data vault has a privacy commitment the tech layer cannot honour.

The architectural posture is therefore: design the A.3 Technological controls from the privacy commitment backward. Start with the A.1 / A.2 privacy commitments; identify the digital surfaces each commitment depends on (the database, the API, the cache, the log, the backup, the endpoint, the development pipeline); verify that the A.3 Technological implementation honours each dependency. The certification auditor traces this backward path: pick an A.1 commitment (e.g. A.1.4.9 disposal) and verify the crypto-shredding pattern; pick an A.1.4.10 transmission control and verify the TLS configuration and the certificate management; pick an A.2.4.4 transmission control on the processor side and verify the in-transit encryption between the processor's services.

The Indian statutory anchors

In India, the A.3 Technological family is statutorily anchored in four overlapping instruments (treated in full in Section 3.2 and mapped in Section 16). DPDP Act 2023 section 8(5), reasonable security safeguards, explicitly extending to integrity, confidentiality and availability of personal data, is the load-bearing Indian anchor; encryption, authentication, logging and backup are the universally-expected technical expressions of the safeguards duty. Section 8(5) failure carries the highest single penalty under the Act (up to two hundred and fifty crore rupees). Section 8(6) is the breach-notification duty on the breach clock (intimation without delay, then a seventy-two-hour report; DPDP Rules 2025 Rule 7); the encryption status of the breached PII is the canonical mitigation the Board weighs. Section 8(7) is the erasure duty, the load-bearing Indian anchor for the crypto-shredding pattern (destroy the key, the ciphertext becomes unrecoverable). Section 10 SDF layers the DPO, SDF DPIA, independent audit and algorithmic-software review. CERT-In Directions 20(3)/2022-CERT-In layers the six-hour clock, the 180-day log retention baseline for the PII-access logs, and the NTP sync for the log time-stamp integrity. The sector-regulator overlays (RBI Storage of Payment System Data; RBI Card-On-File Tokenisation; SEBI CSCRF; IRDAI ICT guidelines) layer additional technology requirements on the regulated entities (Section 21).

Demarcations: PIMS scope vs ISMS scope; A.3 Technological vs generic IT security; what is NOT required

Three demarcations matter for the A.3 Technological family.

PIMS scope vs ISMS scope. In the 2025 standalone structure, the PIMS scope (clause 4.3) defines what the privacy management system covers; the A.3 Technological controls are implemented within the PIMS scope, not across an enterprise-wide ISMS scope. A controller with a broad ISMS scope and a narrower PIMS scope (e.g. the ISMS covers the entire enterprise including the non-PII warehouse management system; the PIMS covers only the customer-facing personal-data processing) can implement A.3 Technological at the PIMS scope, with cross-references to the ISMS evidence base for the broader technological-security discipline. The certification audit tests the A.3 Technological controls at the PIMS scope but accepts evidence from the ISMS where the ISMS scope subsumes the PIMS scope.

A.3 Technological vs generic IT security. The IT function owns the broader technology infrastructure (the network, the cloud accounts, the IAM, the SIEM, the SDLC platform, the secrets manager). The A.3 Technological family does not duplicate IT security, it overlays the PII-protection dimension on the technology infrastructure. The demarcation is documented in the RACI: the CISO / Head of Engineering owns the technology; the DPO owns the PII overlay; the Application Security Lead co-owns the SDLC integration; the Procurement Lead owns the outsourced-development vendor contracts. A common audit finding is an IT-driven technology-security programme with no privacy overlay, the encryption is in place but the encryption inventory does not exist; the logging is in place but the logs capture plaintext PII; the SDLC is in place but the threat model does not identify PII.

What the A.3 Technological family does NOT require. It does not require a separate ISO/IEC 27001 certificate (the 2025 edition is standalone-certifiable). It does not require the full ISO/IEC 27002:2022 theme 8 control set in every PIMS scope (the PIMS selects the controls relevant to its scope; the privacy overlay narrows the selection further, a cloud-only processor with no on-premises infrastructure may exclude the on-prem backup and the on-prem endpoint controls with documented justification). It does not require a specific technology product (the controls are technology-neutral; the controller selects the technology appropriate to the risk and the scope, HSM vs cloud KMS, on-prem SIEM vs cloud SIEM, in-house development vs outsourced). It does not require the DPO to be the CISO (the two roles are distinct; the A.3.4 discipline documents the integration between them).

What auditors actually check

The certification auditor's A.3 Technological examination has six predictable moves (the 25-question checklist is in Section 11). First, walk the PII inventory, pick a PII field in the ROPA and trace where it lives (which database, which table, which column; which non-production copy; which backup; which log); verify the encryption status at each location. Second, walk the key-management discipline, where are the keys stored, who can access them, what is the rotation cadence, what is the escrow arrangement, what is the destruction record. Third, walk the PII-access logging, what does the log capture for a sample PII read transaction; is the time stamp NTP-synced; is the retention at least 180 days; is the log content sanitised (no plaintext PII in the log). Fourth, walk the authentication, is MFA enforced on the internal PII application and the customer-facing application; what is the password policy; how are credentials stored. Fifth, walk the SDLC, pick a recent PII-bearing release and verify the threat model, the privacy requirements, the secure code review, the secrets scan, the test cases, the release gate. Sixth, walk the outsourced-development contract, does it carry the PII clauses; is the right-to-audit present; is the sub-contractor disclosure present; is the cross-border dimension addressed. The encryption inventory, the key-management records and the PII-access log are the three load-bearing evidence artefacts; their absence is the most common major nonconformity at Stage 1.

Why This Control Family Matters

The technological-PII exposure as the privacy credibility test

Of the four PII themes that run through Annex A.1 and the parallel four themes of Annex A.2, none is fully credible without the A.3 Technological backstop in the digital layer. A controller that promises consent withdrawal (A.1.3.5) but cannot locate and purge the principal's PII from the cached non-production copy is making a commitment the tech layer cannot honour. A processor that promises to process only on instructions (A.2.2.x) but allows its engineers to use a shared service-account password on the customer-controller's PII database is making a commitment the tech layer cannot honour. A controller that promises secure retention (A.1.4.8) but ships unencrypted backup tapes to a third-party data vault is making a commitment the tech layer cannot honour.

The A.3 Technological family is the most engineering-heavy of the A.3 themes. The organisational, people and physical controls can be configured through policy, training and facilities discipline; the technological controls require engineering effort, code, configuration, infrastructure, tooling. The technological layer is where the privacy discipline meets the engineering reality, and the engineering reality, in the Indian growing-company segment, is fast-moving, often understaffed, and frequently outsourced. This is why the A.3 Technological family is the most-audited A.3 family in the Indian growing-company segment: the certification auditor's walk through any A.1 or A.2 control will, at some point, land in A.3 Technological. The consent record in A.1.2.5 is stored in a database that must be encrypted, logged and backed up; the rights-request flow in A.1.3.7 runs through an API that must authenticate, authorise and audit; the retention schedule in A.1.4.8 is enforced by a system that must crypto-shred at end-of-life; the transmission discipline in A.1.4.10 runs over TLS that must be configured and certificate-managed. A technological-PII weakness is rarely isolated, it cascades through the privacy commitments that depend on the digital surface.

The Indian regulatory weight

In India, the A.3 Technological family has a regulatory weight that goes beyond the ISO standard itself. The DPDP Act 2023 makes the security safeguards duty (section 8(5)) a statutory duty that explicitly extends to the integrity, confidentiality and availability of personal data, the three dimensions that encryption, authentication, logging and backup collectively operationalise. The breach-notification duty (section 8(6)) operates on the breach clock (intimation without delay; seventy-two-hour report); the encryption status of the breached PII is the canonical mitigation the Board weighs (an encrypted breach is materially less harmful than a plaintext breach, and the controller's notification content reflects this). The erasure duty (section 8(7)) extends to the crypto-shredding pattern for end-of-life data. The CERT-In Directions' six-hour clock applies to the prescribed cyber incidents, including unauthorised access to data, a database breach or a key compromise is squarely within the scope.

The section 8(5) safeguards duty failure carries the highest single penalty under the Act (up to two hundred and fifty crore rupees). The DPBI's enforcement priority will land on the controllers whose safeguards are inadequate, and the technological evidence is the most quantifiable (the auditor asks for the encryption inventory; the auditor asks for the key-management records; the auditor asks for the access logs). The section 8(6) breach-notification duty runs on the breach clock (intimation without delay; seventy-two-hour report); failure to notify carries a separate penalty (up to two hundred crore rupees). The intersection with the CERT-In six-hour clock creates the dual-clock pattern that runs identically for a network-origin breach and a technology-control failure (the Northbound Fintech scenario in Section 14 illustrates the pattern).

The section 8(7) erasure duty is the load-bearing Indian anchor for the crypto-shredding pattern. Where the backed-up or replicated PII cannot be row-level deleted (the operational infeasibility of finding every PII field across every backup, snapshot and replica), crypto-shredding, the destruction of the encryption key protecting the data set, is a defensible erasure technique. The controller's documentation of the crypto-shredding event (the key identifier; the destruction timestamp; the responsible individual; the verification) is the evidence that the section 8(7) duty was met.

The section 10 SDF overlay layers the DPO, SDF DPIA, independent data audit and algorithmic-software review on controllers designated as Significant. The algorithmic-software review overlays ML-specific dimensions (the training-data minimisation; the model-card discipline; the bias-testing), these are increasingly part of the A.3 Technological scope where ML systems consume PII.

The sector-regulator overlays layer additional, more granular technology requirements on BFSI, healthcare and listed-company controllers. The RBI Storage of Payment System Data directive (6 April 2018) effectively requires payment-data localisation, which extends to the cloud-region dimension and the key-custody dimension. The RBI Card-On-File Tokenisation framework (2021–22) replaced the card-on-file storage pattern with a tokenisation pattern, a canonical A.3.26 PII-protection-by-substitution implementation. The SEBI CSCRF (20 August 2024) requires six-hour incident reporting and technology-security controls. The IRDAI Information and Cyber Security Guidelines (24 April 2023) require specific technology controls for insurers and ICT-outsourcers.

The cost of non-compliance

The cost of an A.3 Technological family failure breaks down into four bands.

Direct DPDP penalty exposure for a controller or processor whose A.3 Technological implementation missed a statutory criterion can run to the Schedule maxima, up to two hundred and fifty crore rupees for section 8(5) failure (the unencrypted backup tape; the over-broad production query that exfiltrates the customer table; the shared service-account password); up to two hundred crore for section 8(6) failure (the technological-incident clock missed); up to one hundred and fifty crore for section 10 failure (the SDF DPIA not run within 12 months, or not covering the new ML feature that consumes PII).

Indirect regulatory consequences are larger and slower. An A.3 Technological failure cascades through every privacy commitment that depends on the digital surface, the consent record becomes unverifiable (the consent ledger's integrity is broken because the log was overwritten before the 180-day retention expired); the rights-response becomes inoperable (the erasure request cannot be honoured because the PII is replicated across three backups that cannot be row-level deleted); the breach response becomes evidentially weak (the log does not show who accessed what because the logging was not instrumented on the PII tables); the supplier-chain becomes opaque (the outsourced development vendor retains access to the production PII after the engagement ends). The DPBI, once operational, will request the A.3 Technological evidence base after a complaint or a breach; the absence of the evidence is itself an aggravating factor in the penalty determination.

Commercial cost is significant. The Indian privacy incidents most cited in board rooms, the 2020 grocery-delivery-platform data exposure; the 2021 payment-processor exposure (approximately 35 million card tokens); the 2021 airline/SITA breach (approximately 4.5 million customers); the 2021 healthcare-portal exposure (a state insurance scheme); the 2022 telecom-exposure pattern, all carried post-incident examinations that tested the A.3 Technological family at some point in the chain. For consumer-facing brands, a public A.3 Technological failure (an unencrypted backup tape lost in transit; a database breach made worse because the PII was stored in plaintext) erodes the trust signal the brand spent years building; recovery costs are typically an order of magnitude larger than the prevention cost.

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

The board-level question

The board-level question for the A.3 Technological family is not "do we encrypt?", most controllers encrypt something somewhere. The question is: "if the Data Protection Board asked us tomorrow to produce, for every system that holds PII in the PIMS scope, the encryption inventory (which fields, which algorithm, which key length, which key-management system); for every PII-bearing session, the MFA enforcement record; for every PII read transaction, the access-log entry retained for 180 days; for every PII-bearing backup, the encryption and the restoration test record; for every recent PII-bearing release, the threat model and the privacy sign-off; for every outsourced development engagement, the contract with the PII clauses, could we?" If the honest answer is "partially" or "no", the controller has an A.3 Technological gap regardless of what its IT-security policy says.

Scope and Applicability

Who the family applies to

Table A.3 sits in the 2025 Annex A as the single security-control set for both controllers and processors. Unlike A.1 (controllers) and A.2 (processors), A.3 binds every organisation in the PIMS scope regardless of role. The A.3 Technological family is no exception, it applies to the controller operating its own customer-facing processing, the processor operating its customer-controller's processing, and the mixed controller-and-processor operating both. The dual-applicability is the load-bearing structural point: the technological-security discipline does not change because the organisation's role changes. A processor's encryption discipline is no weaker than a controller's; a processor's logging discipline is no weaker than a controller's. The privacy overlay varies by role (a processor's outsourced-development contract propagates the customer-controller's instructions; a controller's outsourced-development contract includes its own A.1.2.7-derived clauses), but the underlying technological discipline is the same.

The technological-theme controls in this guide bind every organisation that processes personal data in the PIMS scope, from a two-person startup running a single lead-capture form with no on-premises infrastructure, to a thousand-person fintech running dozens of processing activities across multiple cloud accounts with complex SDLC and multiple outsourced vendors, to a Significant Data Fiduciary under DPDP section 10 with a multi-cloud, multi-jurisdiction, ML-heavy technology estate. The maturity expectations scale with the volume, sensitivity and digital surface of the processing, see Section 22 (Maturity Model). The controls scale too: a SaaS-only processor with no on-premises infrastructure may implement only the cloud-region, key-management and SDLC controls and exclude the on-prem backup and the endpoint controls (which the cloud provider handles) with documented justification; a branch-based BFSI controller implements the full set across every branch and the corporate technology stack.

When the family applies

The A.3 Technological family is always-on. The endpoint device (A.3.22) is governed every minute a PII session is open; the authentication (A.3.23) is enforced on every login; the backup (A.3.24) runs on its schedule and the restoration test runs on its cadence; the logging (A.3.25) captures every PII read transaction; the cryptography (A.3.26) protects every PII field at rest, in transit and (where supported) in use; the SDLC (A.3.27 / A.3.28 / A.3.29) governs every release; the outsourced development (A.3.30) governs every vendor engagement.

What is in scope for the A.3 Technological artefacts

The A.3 Technological family's artefact set covers every digital surface that touches PII in the PIMS scope. This includes:

• PII-bearing systems, production databases, application servers, API gateways, message queues, caches, search indexes, analytics warehouses, ML feature stores, ML models in inference.
• PII in transit, every network path that carries PII (the customer-to-edge path; the edge-to-application path; the application-to-database path; the service-to-service east-west path; the application-to-third-party-API path; the application-to-backup path).
• PII at rest, every storage medium that holds PII (the production database; the read replica; the cache; the search index; the analytics warehouse; the backup; the snapshot; the log; the non-production copy; the local cache on the endpoint).
• PII in logs, every log that captures PII (the application log; the database query log; the API gateway log; the SIEM events; the audit trail). The canonical A.3.25 tension: the log must capture enough to evidence the access, but must not capture so much that the log itself becomes a PII surface.
• PII in backups, every backup that contains PII (the database backup; the volume snapshot; the cross-region replication; the long-term archive).
• PII on endpoints, every endpoint that opens a session on a PII-bearing system (the customer-support agent's desktop; the relationship manager's laptop; the underwriter's tablet; the engineer's laptop with production access; the customer's mobile phone running the controller's app).
• PII in the SDLC, every development surface that touches PII (the production data copy used in test; the secrets in source code; the third-party library that processes PII; the build pipeline; the deployment manifest).
• PII in outsourced development, every vendor engagement that builds or operates a system touching PII.

What is out of scope

• PII-free systems, a system that processes no personal data (e.g. an internal inventory-management system for an SKU-only warehouse) is out of scope for the PII overlay, though the broader ISMS may still cover it.
• Anonymous data, if the data does not relate to an identifiable principal (true anonymisation, not pseudonymisation), the A.3 Technological PII overlay does not apply. Pseudonymised data is still personal data under DPDP and GDPR; the A.3 overlay applies in full (the re-identification key is in scope).
• Pure infrastructure data (network topology, configuration baselines) that does not relate to identifiable principals, though the SIEM events and the audit trail that capture user identifiers are in scope.
• Public-sector exemptions under DPDP section 17 (state processing) where the exemption applies, note the exemption is narrow.

Applicability by organisation size

Key Definitions and Terminology

The A.3 Technological family draws terms from ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27701:2025, the DPDP Act 2023, and the broader security-engineering literature. The load-bearing terms below appear throughout the guide.

• PII (personally identifiable information), any information that can be used to identify a PII principal directly or indirectly. The 27701 term; the DPDP analogue is "personal data" (section 2(1)(o)).
• PII controller (Data Fiduciary), the organisation that determines the purposes and means of PII processing. A.1 controls bind the controller.
• PII processor (Data Processor), the organisation that processes PII on behalf of a controller. A.2 controls bind the processor.
• Encryption at rest, the cryptographic protection of PII stored on a persistent medium (the production database; the backup; the cache; the log; the endpoint's local storage). The load-bearing technical expression of the section 8(5) confidentiality dimension. Algorithms: AES-256 (symmetric) is the typical standard; ChaCha20 (in constrained environments) is acceptable.
• Encryption in transit, the cryptographic protection of PII as it moves over a network. The load-bearing technical expression of the section 8(5) confidentiality dimension for the network path. Protocols: TLS 1.2 minimum (TLS 1.3 preferred); mTLS for service-to-service east-west.
• Encryption in use, the cryptographic protection of PII while it is being processed (homomorphic encryption; secure enclaves; trusted execution environments). Emerging practice; applicable to high-sensitivity PII in specialised use-cases.
• Tokenisation, the substitution of PII with a non-sensitive token that has no exploitable meaning outside the system that issued it. The canonical A.3.26 PII-protection-by-substitution pattern; the RBI Card-On-File Tokenisation framework is a sector-specific instance.
• Field-level encryption, the encryption of specific PII fields within a larger record (e.g. encrypt the PAN column, leave the customer name column in plaintext). The canonical A.3.26 pattern for selective PII protection.
• Key management, the lifecycle discipline for the cryptographic keys that protect PII: generation (using a vetted random-number generator); rotation (at a defined cadence, e.g. annually for data-encryption keys); storage (in a KMS, HSM, or cloud-KMS); escrow (the break-glass recovery path); destruction (the crypto-shredding event). The load-bearing A.3.26 operational artefact.
• KMS (Key Management Service), the platform that creates, stores, rotates and controls access to cryptographic keys. Examples: a cloud-KMS (the Indian-region cloud-KMS); an on-prem HSM (Hardware Security Module); a vault.
• HSM (Hardware Security Module), the physical or virtual hardware that generates and stores cryptographic keys, with physical tamper-resistance and a defined trust boundary. The high-assurance key-management option; the typical choice for the most-sensitive PII (payment data, biometric data).
• Crypto-shredding, the erasure technique whereby the encryption key protecting a data set is destroyed, rendering the ciphertext unrecoverable. The canonical end-of-life erasure pattern for backed-up and replicated data; the technical expression of the section 8(7) erasure duty where row-level deletion is infeasible.
• MDM (Mobile Device Management), the platform that enforces the device-level configuration: full-disk encryption, screen-lock, remote-wipe, application allow-listing, policy enforcement. The canonical A.3.22 enforcement lever for endpoints.
• MFA (Multi-Factor Authentication), the authentication pattern that requires two or more factors (something the user knows, has, or is). The canonical A.3.23 enforcement lever for PII-bearing sessions.
• SIEM (Security Information and Event Management), the platform that aggregates, correlates and analyses logs from across the technology stack. The canonical A.3.25 enforcement lever for PII-access logging at scale.
• DLP (Data Loss Prevention), the platform that monitors and blocks the movement of PII from authorised locations to unauthorised channels (the copy to USB; the upload to unauthorised cloud storage; the email to an external address).
• SDLC (Software Development Life Cycle), the process by which software is conceived, specified, designed, built, tested, deployed, operated and retired. The A.3.27 / A.3.28 / A.3.29 controls attach to the SDLC.
• Threat modelling, the structured analysis of a system's attack surface, the threats to it, and the controls that mitigate the threats. The canonical A.3.29 activity at the design stage.
• Privacy-by-design checklist, the engineering checklist that ensures PII is identified and protected at every stage of the SDLC. The A.3.27 / A.3.28 operational artefact.
• Outsourced development, the engagement of an external vendor to build or operate a system that touches PII. The A.3.30 control attaches to this engagement.
• PII inventory, the controller's or processor's record of every system, every field, every flow that touches PII. The foundational artefact that drives the A.3 Technological implementation; reconciles to the ROPA under A.1.2.9.
• Ransomware, the malware category that encrypts the victim's data and demands payment for the decryption key. The canonical A.3.24 / A.3.26 incident scenario where the backup's offline or immutable slice is the recovery path.
• NTP (Network Time Protocol), the protocol used to synchronise ICT clocks; mandated by CERT-In Directions to a defined Indian reference (the NIC NTP server). The log time-stamp integrity dimension.

Relationship to Other Controls

Within the A.3 family (across the four themes)

The A.3 Technological family is one of four themes in Table A.3. The other three themes, Organisational (covered in the Singahi A.3 Organisational Controls guide), People (covered in the Singahi A.3 People Controls guide) and Physical (covered in the Singahi A.3 Physical Controls guide), provide the organisational, human-layer and physical-layer backstops that complement the technological layer. The densest intra-family intersections: A.3.3 / A.3.16 (policies, the Technological-Security Policy with the PII overlay sits here); A.3.9 (access rights, the policy dimension that complements A.3.23 authentication, which is the enforcement); A.3.10 (supplier agreements, A.3.30 outsourced development is the slice); A.3.11 (incident-management planning and preparation, the readiness behind the response); A.3.12 (incident response, the technological-incident scenarios); A.3.14 (records protection, the log-integrity dimension); A.3.17 (awareness, the secure-coding training); A.3.19 to A.3.21 (physical, the endpoint and the backup tape intersect the technological-device layer).

To the A.1 controller privacy controls

The A.3 Technological family is the digital backstop for the A.1 controller privacy controls. The densest overlaps: A.1.2.5 (consent ledger is a PII-bearing system; depends on A.3.26 encryption and A.3.25 logging); A.1.2.9 records of processing (the PII inventory reconciles to the ROPA); A.1.3.7 (rights-request flow runs through an API that must authenticate, authorise, audit; erasure honoured through crypto-shredding); A.1.4.5 PII minimisation (limits what the tech layer must protect); A.1.4.7 temporary files (the cache layer, often forgotten); A.1.4.8 retention (drives the crypto-shredding schedule); A.1.4.9 disposal (A.3.26 crypto-shredding operationalises this at the digital layer); A.1.4.10 PII transmission controls (the in-transit slice, TLS, certificates, mTLS).

To the A.2 processor privacy controls

• A.2.2.5 infringing instruction, when the controller's instruction requires the processor to weaken a technical control (share a service-account password; disable MFA for a key integration), the processor escalates under A.2.2.5 rather than executes.
• A.2.4.3 return, transfer or disposal of PII, the crypto-shredding event when the processor's contract ends is the canonical A.2.4.3 / A.3.26 intersection.
• A.2.4.4 PII transmission controls, the in-transit encryption discipline on the processor's services.

To the MSS clauses

Clause 4.3 (scope, defines the digital perimeter); Clause 5.3 (roles, DPO and CISO integration); Clause 6.1 (risk, selects the A.3 Technological controls and justifies exclusions); Clause 7.5 (documented information, encryption inventory, key-management records, access logs, backup-restoration tests, SDLC artefacts); Clause 8.1 (operational planning and control); Clause 9.1 (monitoring, the KPIs in Section 12); Clause 9.2 (internal audit); Clause 10.2 (nonconformity, the post-incident review).

To the CERT-In Directions and the dual-clock pattern

The CERT-In Directions intersect the A.3 Technological family at three points. First, the six-hour clock applies to the prescribed cyber incidents, including unauthorised access to systems and data, ransomware, and data breaches. A key compromise, a database breach, a ransomware event, a log integrity failure, each engages the CERT-In clock from awareness. Second, the 180-day log retention mandate sets the baseline for the PII-access logs (the A.3.25 dimension). Third, the NTP sync mandate sets the time-stamp integrity baseline. The dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks) operates identically for a technological-incident and a network-origin breach, the Northbound Fintech scenario (Section 14) illustrates the technological-origin pattern.

Detailed Implementation Guidance, Control by Control

This section is the operational core of the guide. Each of the ten controls (A.3.22 to A.3.31) is treated in three layers: the requirement (paraphrased), the PII-protection angle beyond the generic security baseline, and the DPDP-first implementation pointer (with cross-references to the Singahi ISO/IEC 27001 / 27002 library for the generic security depth). The treatments are deliberately condensed, the A.3 condensed series leans on the 27001 library for the security depth and adds the privacy overlay that makes each control PIMS-relevant.

A.3.22, User endpoint devices (the endpoint-PII control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.22, aligned to ISO/IEC 27002:2022 control 8.1, asks PII controllers and processors to govern the user endpoint devices that access, store or process PII, through registration, configuration, encryption, monitoring and retirement, so that PII on the endpoint is protected across its lifecycle.

The PII-protection angle. A generic MDM configuration is not sufficient in a PIMS scope; the configuration must name PII explicitly. The load-bearing sub-controls: full-disk encryption on every endpoint that may hold PII locally; screen-lock enforcement (5 minutes on laptops; 1 minute on mobile; the user unable to disable); remote-wipe capability; container separation on BYOD (the work-profile wiped without affecting the personal profile); application allow-listing and a DLP agent that blocks PII egress to USB and unauthorised cloud storage. The endpoint is the principal's first surface of interaction with the controller; the privacy overlay ensures it does not become a leakage surface.

DPDP-first implementation. Section 8(5) is the load-bearing Indian anchor. The lost-laptop-with-cached-PII breach scenario engages the dual-clock pattern under A.3.12, with the encryption status as the canonical mitigation (if the disk was encrypted and the key was not compromised, the breach's harm to principals is materially lower).

A.3.23, Secure authentication (the gate control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.23, aligned to ISO/IEC 27002:2022 control 8.5, asks PII controllers and processors to enforce secure authentication on every system that processes PII, through appropriate authentication mechanisms, credential management, and session discipline.

The PII-protection angle. The load-bearing sub-controls: MFA on every PII-bearing session (customer-facing; internal customer-support; engineer's production; administrator's cloud-account); the password policy aligned to NIST SP 800-63B (length minimum 12; breach-history check; no forced rotation); credential storage salted and hashed with a memory-hard function (bcrypt, scrypt, argon2); session-management with token rotation, idle timeout and concurrent-session control; step-up authentication for high-risk operations (consent withdrawal; profile changes; PII exports); the service-account discipline (no shared passwords; secrets in a vault; rotation at a defined cadence). The most common A.3.23 audit failure in the Indian growing-company segment is the MFA-on-customer-app-but-not-on-internal-tool pattern.

DPDP-first implementation. Section 8(5) is the load-bearing Indian anchor, authentication operationalises the access-control dimension. The RBI two-factor requirement for payment transactions and the SEBI CSCRF authentication expectations layer sector-specific overlays.

A.3.24, Information backup (the restorability-and-PII-residue control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.24, aligned to ISO/IEC 27002:2022 control 8.13, asks PII controllers and processors to maintain backups of PII-bearing systems, with a defined scope, frequency, retention, encryption, and restoration-test discipline, so that PII is recoverable across an outage, a ransomware event, or a system failure.

The PII-protection angle. Two overlays matter. First, the backup-encryption discipline: every PII-bearing backup must be encrypted at rest, with a separate key (the backup key is not the production-database key, the compromise of one must not compromise the other). Second, the ransomware-resilience dimension: the offline or immutable (WORM) backup slice that survives a ransomware encryption event on the production estate. Without the offline slice, the controller's only recovery path is paying the ransom, itself a section 8(5) availability-dimension failure. The restoration-test cadence (typically quarterly) must include a PII-restoration verification. The cross-border dimension (DPDP section 16): the cross-region replication that puts a copy of the Indian PII in a non-Indian region must be screened against any country restriction the Central Government notifies under section 16(1).

DPDP-first implementation. Section 8(5) (the availability dimension) is the load-bearing Indian anchor. Section 8(6) is the breach dimension, a lost or stolen backup tape is a personal-data breach, with the encryption status as the canonical mitigation. The RBI Storage of Payment Data directive layers payment-data localisation on the backup strategy.

A.3.25, Logging (the evidence-base control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.25, aligned to ISO/IEC 27002:2022 control 8.15, asks PII controllers and processors to produce, protect and retain logs that record user activities, exceptions, faults, and information-security events, so that the controller can investigate incidents, evidence compliance, and reconstruct what happened to PII.

The PII-protection angle. Two dimensions in tension. First, the access-evidence dimension: the log must capture enough to evidence every PII read transaction (who, what, when, from where). This is the canonical A.1.3.7 (access, correction or erasure) evidence chain, when the principal asks "who has accessed my data?", the answer comes from the access log. Second, the log-content dimension: the log must not capture plaintext PII in the first place. The canonical A.3.25 anti-pattern is the application log that captures the full request body including the PII payload, the log becomes a secondary PII surface (and a secondary breach surface). The log-sanitisation pattern (mask the PII fields; log the field names or hashed references) is the operational discipline. The SIEM aggregation with 180-day retention (the CERT-In baseline) is the at-scale pattern. The NTP-synced time stamps are the integrity dimension.

DPDP-first implementation. Section 8(5) (the integrity dimension) is the load-bearing Indian anchor. Section 8(6) makes the log the breach-evidence base. The CERT-In Directions' 180-day retention and NTP-sync mandates are the operational baselines.

A.3.26, Use of cryptography (the load-bearing PII control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.26, aligned to ISO/IEC 27002:2022 control 8.24, asks PII controllers and processors to develop and implement a cryptography discipline, covering when, where and how cryptography is used to protect information, and the key-management lifecycle that supports it, appropriate to the sensitivity of the information and the risk to which it is exposed.

The PII-protection angle. This is the load-bearing PII control in the A.3 Technological family. The A.3.26 PII overlay has four sub-controls. (i) PII at rest encryption, every PII-bearing storage medium encrypted with AES-256 (or equivalent). The encryption inventory, which systems, which fields, which algorithm, which key length, which KMS, which key identifier, reconciles to the ROPA under A.1.2.9. Field-level encryption is the canonical pattern for selective PII protection; tokenisation is the canonical pattern for high-sensitivity PII at scale (the RBI Card-On-File Tokenisation framework is a sector-specific instance). (ii) PII in transit encryption, TLS 1.2 minimum (TLS 1.3 preferred) on every network path that carries PII, including internal east-west (mTLS for service-to-service). The certificate-management discipline, inventory, expiry monitoring, automated renewal, is the load-bearing operational artefact. Self-signed certificates on internal PII-bearing APIs are the most common A.3.26 audit failure in the Indian growing-company segment. (iii) PII in use encryption, tokenisation or field-level encryption extends to the in-use slice where the use-case supports it; the application reads the token, not the PII; the de-tokenisation flow is controlled. The emerging practice is the secure-enclave / trusted-execution-environment pattern for the highest-sensitivity PII. (iv) The key-management lifecycle, generation (vetted random-number generator; never a custom algorithm); rotation (annually for data-encryption keys; per-release for application keys); storage (in a KMS, HSM or cloud-KMS, never in source code, never in CI/CD variables, never in plaintext configuration); escrow (the break-glass recovery; multi-party control); destruction (the crypto-shredding event). Key-custodian separation, the person who can use the key cannot administer the KMS; the person who administers the KMS cannot use the key, is the high-assurance pattern.

DPDP-first implementation. Section 8(5) is the load-bearing Indian anchor, encryption is the technical expression of the confidentiality dimension. The DPBI's penalty calculus after a breach explicitly weighs the encryption status. Section 8(7) is the erasure dimension, the crypto-shredding pattern is the canonical end-of-life erasure technique for backed-up and replicated data. The RBI Storage of Payment Data directive and the RBI Card-On-File Tokenisation framework layer sector-specific cryptography requirements. The Madhuram Health Insurance scenario (Section 15) illustrates the A.3.26 PII-aware crypto-layer build.

A.3.27, Secure development life cycle (the SDLC control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.27, aligned to ISO/IEC 27002:2022 control 8.25 (with 8.28 secure coding as the practice-level control), asks PII controllers and processors to embed security and privacy into the development life cycle, through threat modelling, secure coding standards, code review, testing and release gates, so that systems are built with protection by design rather than retrofitted later.

The PII-protection angle. The privacy-by-design checklist (toolkit doc 03) integrated into every stage of the SDLC. At requirements: what PII does the feature collect, why, for how long, who can access it, what is the lawful basis. At design: the threat model identifies PII as a Crown Jewel asset; the data-flow diagram traces every PII path; the threats (unauthorised read/write; excessive collection; unauthorised retention) are catalogued; the controls specified. At build: secure-coding standards address PII mishandling explicitly (no PII in log statements, error messages, cache keys without expiry, URL parameters, client-side storage without encryption, commit messages or test fixtures). Dependency and secrets scanning catches third-party PII processors and embedded secrets. At test: privacy test cases verify the protection, the negative test (does the API return PII when it should not?); the minimisation test (does the API return more PII than the consumer needs?); the retention test (does the system actually delete or anonymise at the retention boundary?). At release: the privacy gate, no PII-bearing release ships without the privacy sign-off. The release-gate pattern is the load-bearing enforcement lever.

DPDP-first implementation. Section 8(5) is the load-bearing Indian anchor; the A.3.27 SDLC is the technical operationalisation of the A.1.4 by-design commitment. Section 10 SDF overlays the algorithmic-software dimension where ML is in scope.

A.3.28, Application security requirements (the API-and-UI control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.28, aligned to ISO/IEC 27002:2022 control 8.26, asks PII controllers and processors to specify and enforce application-level security requirements, the API contracts, the user-interface behaviour, the input validation, the error handling, that protect PII at the application layer.

The PII-protection angle. Four sub-controls. First, PII minimisation at the API contract: the API returns only the PII fields the consumer needs (the customer-support API returns name and contact; the underwriter API adds the financial fields). The over-returning API is the canonical anti-pattern. Second, PII masking in the UI: the agent sees the masked last-4 of the PAN; the underwriter sees the full PAN; the "view" permission controls the unmasking. Third, rate-limiting to prevent PII enumeration: the API enforces a per-caller rate limit; the scripted-sequential-customer-ID attack is blocked. Fourth, input validation and error handling: validation prevents injection-based PII exfiltration; the error handler does not leak PII in stack traces or verbose error messages.

DPDP-first implementation. Section 8(5) is the load-bearing Indian anchor. The minimisation dimension overlaps with A.1.4.5, the A.3.28 application-layer minimisation is the technical operationalisation of the A.1.4.5 commitment.

A.3.29, Secure system architecture and engineering (the architecture control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.29, aligned to ISO/IEC 27002:2022 control 8.27, asks PII controllers and processors to design, build and operate the system architecture so that PII is protected across the stack, through segmentation, secret management, privileged-access management, and secure-by-design patterns for new systems.

The PII-protection angle. Four sub-controls. First, segmentation: the PII-bearing systems are isolated from the corporate network; the engineer's laptop cannot directly reach the production database; the database is reachable only through the application layer. Second, privileged-access management (PAM): administrative accounts on PII systems are brokered through a PAM platform, credential checked out for a defined window, session recorded, just-in-time elevation logged. The shared service-account password is the canonical anti-pattern. Third, secret management: secrets (database passwords, API keys, crypto keys) in a vault, not in source code, not in CI/CD variables, not in plaintext configuration. Fourth, secure-by-design for new systems: every new PII-touching system goes through an architecture review that identifies the PII flows and the controls each flow requires. The cloud-region discipline, PII stored in the Indian region where the regulator requires localisation, is the load-bearing architectural decision.

DPDP-first implementation. Section 8(5) is the load-bearing Indian anchor; section 16 overlays the cloud-region discipline.

A.3.30, Outsourced development (the vendor-development control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.30, aligned to ISO/IEC 27002:2022 control 8.30, asks PII controllers and processors to extend the secure-development discipline to vendors and sub-contractors who build or operate systems that touch PII, through contract clauses, secure-coding training, audit rights, and sub-contractor disclosure.

The PII-protection angle. The A.3.30 PII overlay propagates A.3.27 / A.3.28 / A.3.29 to the vendor base. The load-bearing contract clauses (toolkit doc 10): the vendor shall apply the controller's secure-development standards; shall complete the privacy-by-design checklist for every PII-bearing feature; the vendor's engineers shall complete secure-coding training; the controller shall have the right to audit (or rely on the vendor's ISO/IEC 27001 / SOC 2 attestation); the vendor shall disclose all sub-contractors and notify changes in advance; the vendor shall not retain the controller's PII after the engagement ends; the cross-border dimension (DPDP section 16) on the vendor's engineering location; the breach-notification SLA that lets the controller meet the dual-clock pattern.

DPDP-first implementation. Section 8(5) (the vendor is the controller's agent for the safeguards duty), section 8(6) (the breach flow through the vendor), section 11 (the controller-processor contract, the development vendor is a processor if it touches PII) and section 16 (the cross-border dimension) are the load-bearing Indian anchors. The vendor-security questionnaire (toolkit doc 10) operationalises the section 8(5) flow-down.

A.3.31, Test information (the non-production-PII control)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.31, aligned to ISO/IEC 27002:2022 control 8.33, asks PII controllers and processors to select, protect and manage test information appropriately, so that data used to test systems that process PII does not itself become an unprotected copy of production personal data.

The PII-protection angle. A.3.31 closes the most-overlooked PII leak in the technological theme: the production database restored into a staging or UAT environment "just for testing". That copy typically sits outside the A.3.9 access model, outside the A.3.25 logging discipline, sometimes outside the A.3.26 encryption baseline, and almost always outside the A.1.4.8 retention schedule, while containing the same personal data as production. It is also invisible to the principal-rights machinery: an erasure executed under A.1.3.7 against production does not reach the six-month-old staging snapshot, so the organisation reports an erasure it has not actually completed. The overlay has four parts:

• Prefer synthetic or de-identified test data. Where production-derived data is genuinely necessary, apply the A.1.4.6 de-identification discipline before it leaves production, and record the decision.
• Bound the copy. Every non-production copy carries an owner, a documented purpose, an expiry date and an automated deletion job, the same retention discipline as production.
• Protect it like production. If it holds real PII, it inherits the production controls: access model (A.3.9), encryption (A.3.26), logging (A.3.25), backup treatment (A.3.24).
• Inventory it. Non-production environments belong in the ROPA (A.1.2.9) and the data map, otherwise the propagation obligations under A.1.3.7 and A.1.4.9 cannot be met.

DPDP-first implementation. An unprotected test copy of personal data is a section 8(5) reasonable-security-safeguards failure on its own terms, and its compromise is a section 8(6) personal data breach with the full two-stage Rule 7 clock. It also undermines section 12 correction-and-erasure compliance, because the principal's erasure has demonstrably not propagated. For SDFs, the SDF DPIA under section 10 should explicitly cover the non-production environments. The practical Indian pattern for growing companies: a masked-refresh pipeline that de-identifies on export, plus a quarterly reconciliation that lists every non-production environment holding PII and its expiry date.

The integration, the eight layers as one operating model

The A.3 Technological family operates as a single layered architecture. The endpoint layer (A.3.22) is the user's seat; the authentication layer (A.3.23) gates access; the crypto layer (A.3.26) makes the PII unreadable to unauthorised parties; the logging layer (A.3.25) records what happened; the backup layer (A.3.24) preserves restorability; the engineering layers (A.3.27 / A.3.28 / A.3.29) build the protection in; and the outsourced layer (A.3.30) propagates the discipline to the vendor base. A controller or processor that holds the layers as one coherent engineering architecture will pass an A.3 Technological audit; a controller that holds each layer as a disconnected IT duty will pass the paperwork but fail the operational test.

The Singahi recommended pattern is to operate the seven layers through a single PII-aware engineering operating model, a unified engineering governance committee (the CISO, the Head of Engineering, the DPO, the Application Security Lead, the Procurement Lead) that owns the technology-PII discipline; a unified PII inventory that drives the encryption, the logging, the backup and the SDLC; a unified key-management discipline; a unified logging pipeline to the SIEM; a unified incident-response programme that runs the technological-incident scenarios with the dual-clock pattern. The operating model is documented in the RACI (toolkit doc 13) and the roles and responsibilities (toolkit doc 16).

Tools, Technologies, and Solutions

The A.3 Technological controls are largely engineering controls, and several tool categories are load-bearing. This section sketches the landscape; the vendor-evaluation questionnaire and the build-vs-buy framework are in toolkit doc 14 (Tool Comparison Matrix).

Key Management Service (KMS) and Hardware Security Module (HSM), A.3.26 backbone

The KMS or HSM is the load-bearing A.3.26 platform. The categories relevant to the A.3.26 PII overlay:

• Cloud-KMS, the cloud provider's managed KMS (the Indian-region service for the Indian PII). The canonical choice for most growing companies and mid-sized (250 to 2,000) firms. The keys are generated, stored, rotated and accessed through the cloud-KMS API; the access is logged in the cloud-audit trail.
• On-prem HSM, the physical or virtual hardware that generates and stores the most-sensitive keys. The high-assurance choice for the highest-sensitivity PII (payment data; biometric data; the SDF's crypto-asset base). The typical pattern is the cloud-KMS for the application keys and the on-prem HSM for the highest-sensitivity keys.
• Vault, the open-source or commercial secrets manager that holds database passwords, API keys, certificates. The canonical choice for the secrets-management dimension of A.3.29.

SIEM (Security Information and Event Management), A.3.25 backbone

The SIEM is the load-bearing A.3.25 platform for the PII-access-logging aggregation. The categories relevant to the A.3.25 PII overlay:

• Cloud-SIEM, the cloud provider's managed SIEM (or a SaaS SIEM). The canonical choice for most growing companies and mid-sized (250 to 2,000) firms. The log ingestion, the correlation rules, the dashboards, the alerting are managed services; the 180-day retention is a configuration choice.
• On-prem SIEM, the traditional on-prem SIEM (open-source or commercial). The choice for the regulated sectors that require on-prem log storage (RBI payment-data localisation extends to the access logs of the payment systems).

The retention extension to multiple years (for the highest-sensitivity PII zones) adds storage cost on a per-TB basis.

MDM (Mobile Device Management) and EDR (Endpoint Detection and Response), A.3.22 backbone

MDM and EDR are the load-bearing A.3.22 platforms for the endpoint layer. MDM enforces the configuration (full-disk encryption; screen-lock; remote-wipe; application allow-listing); EDR detects and responds to endpoint threats (the malware that exfiltrates PII; the unauthorised software that accesses the PII cache). The DLP platform extends the endpoint discipline to the PII-egress dimension (the copy to USB; the upload to unauthorised cloud storage).

SDLC tooling, A.3.27 / A.3.28 / A.3.29 backbone

The SDLC tooling integrates the privacy-by-design checklist into the engineering workflow. The categories relevant to the A.3.27 / A.3.28 / A.3.29 PII overlay:

• Threat-modelling platforms, the structured-analysis platforms that document the data-flow diagram, the threats, the controls.
• SAST (Static Application Security Testing), the source-code scanning that catches the PII-mishandling patterns (the log statement with PII; the error message with PII; the hardcoded PII in test fixtures).
• DAST (Dynamic Application Testing), the runtime testing that catches the PII exposure patterns (the over-returning API; the verbose error with PII; the rate-limit gap that allows enumeration).
• SCA (Software Composition Analysis), the dependency scanning that identifies the third-party libraries that process PII.
• Secrets-scanning platforms, the scanning that catches the secrets in source code, in CI/CD variables, in container images.
• Container and infrastructure-as-code scanning, the scanning that catches the misconfiguration in the deployment manifest (the public S3 bucket with PII; the open security group on the PII database).

The integration with the existing CI/CD pipeline is the load-bearing implementation effort.

Backup and ransomware-resilience platforms, A.3.24 backbone

The backup platform and the ransomware-resilience layer are the load-bearing A.3.24 platforms. The categories relevant to the A.3.24 PII overlay:

• Cloud-backup platforms, the managed backup services with built-in encryption (the backup-encryption-key separate from the production-database key).
• Immutable or WORM (Write Once Read Many) backup targets, the backup slice that cannot be modified or deleted by the ransomware (the canonical ransomware-resilience pattern).
• Offline backup, the air-gapped backup slice (the tape carousel; the offline-disk store) for the highest-assurance ransomware resilience.
• Restoration-test automation, the platform that automates the restoration test on cadence and produces the restoration-test evidence.

The make-vs-buy decision

The make-vs-buy decision for the A.3 Technological tooling weighs the size of the PIMS scope, the complexity of the technology estate, the maturity target, and the Indian-market context. The recommended pattern:

• Growing companies (50 to 250 staff), typically buy the cloud-KMS, the cloud-SIEM, the MDM, the cloud-backup. The build-vs-buy trade favours buy at this scale. The SDLC tooling (SAST, SCA, secrets-scanning) is typically bought as a single platform.
• Mid-sized (250 to 2,000 staff), buy the full tooling stack (cloud-KMS or on-prem HSM; cloud-SIEM or on-prem SIEM; MDM + EDR + DLP; SDLC tooling; backup + ransomware-resilience). The integration effort is the load-bearing investment.
• Enterprise / SDF, buy the full tooling stack with the multi-cloud and multi-jurisdiction integration; the unified PII-platform layer (the integrated PII inventory; the integrated key-management; the integrated logging pipeline; the integrated SDLC gate) is the make dimension where the proprietary integration adds value.

Policy and Procedure Templates

The Singahi A.3 Technological toolkit (this guide's companion artefact set) includes the load-bearing policy and procedure templates. The full templates are in the toolkit; the section below summarises the structure and the headline "shall" clauses (Singahi-authored drafting samples for the organisation to adopt, customise and own).

The Technological-Security Policy with the PII overlay (toolkit doc 01)

The Technological-Security Policy is the topic-specific policy under A.3.3 (compliance tested under A.3.16) that operationalises the A.3 Technological family. The headline "shall" clauses:

• The organisation shall implement its technological security controls with a PII-aware posture; every A.3 Technological control shall have a documented privacy overlay.
• The organisation shall maintain the PII inventory reconciled to the ROPA.
• The organisation shall encrypt PII at rest everywhere it lives (production, non-production, backups, logs, caches) with AES-256 (or equivalent) and a documented key-management lifecycle.
• The organisation shall encrypt PII in transit with TLS 1.2 minimum (TLS 1.3 preferred) everywhere, including internal east-west traffic.
• The organisation shall enforce MFA on every PII-bearing session.
• The organisation shall maintain the PII-access logging discipline; the log content shall be sanitised (no plaintext PII); the retention shall be at least 180 days within Indian jurisdiction.
• The organisation shall encrypt backups; the offline or immutable slice shall be maintained for ransomware resilience; the restoration test shall include a PII-restoration verification.
• The organisation shall integrate the privacy-by-design checklist into the SDLC; no PII-bearing release shall ship without the privacy sign-off.
• The organisation shall flow down the same requirements to outsourced development vendors under the contract clauses.

The PII Encryption and Cryptography Procedure (toolkit doc 02)

The procedure operationalises A.3.26. The headline "shall" clauses:

• The PII encryption inventory shall be documented and reconciled to the ROPA.
• AES-256 (or equivalent) shall be the minimum standard for PII at rest; TLS 1.2 (or higher) shall be the minimum standard for PII in transit.
• The keys shall be generated, stored, rotated and destroyed through the KMS or HSM; the key-custodian separation shall be enforced.
• The key rotation cadence shall be documented per key type (data-encryption keys annually; application keys per release).
• The crypto-shredding pattern shall be applied for end-of-life PII where row-level deletion is infeasible.
• The self-signed certificate on a PII-bearing API shall not be permitted; the certificate-management discipline shall be enforced.

The PII Access Logging Procedure (toolkit doc 03)

The procedure operationalises A.3.25. The headline "shall" clauses:

• Every PII read transaction shall be logged (who, what, when, from where).
• The log content shall not include plaintext PII; the log-sanitisation pattern shall be applied.
• The logs shall be aggregated to the SIEM; the retention shall be at least 180 days within Indian jurisdiction.
• The time stamps shall be NTP-synced per the CERT-In Directions.
• The principal's access request shall be answerable from the logs; the access-evidence chain shall be demonstrable.

The Cryptographic Incident Response Playbook (toolkit doc 08)

The playbook operationalises A.3.12 for the cryptographic-incident scenarios. The headline scenarios: the key compromise (the KMS breach; the HSM breach; the credential leak); the database breach (the SQL injection that exfiltrates PII; the insider query that exports the customer table); the ransomware event with PII at stake; the backup-tape loss; the log integrity failure. Each scenario runs the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks where applicable) and the principal-notification decision tree, with the encryption status as the canonical mitigation.

The Outsourced Development Security Schedule (toolkit doc 10)

The schedule operationalises A.3.30. The headline "shall" clauses (the vendor's commitments):

• The vendor shall apply the controller's secure-development standards.
• The vendor shall complete the privacy-by-design checklist for every PII-bearing feature.
• The vendor shall notify the controller of any security or privacy incident within the time limit that lets the controller meet the dual-clock pattern.
• The vendor shall disclose all sub-contractors and shall notify the controller of any change in advance.
• The vendor shall not retain the controller's PII after the engagement ends.

Risk Assessment and Treatment

The Singahi A.3 Technological-family risk register (toolkit doc 09) is the asset-threat-vulnerability-risk matrix that drives the A.3 Technological risk-treatment plan. The register is structured per ISO/IEC 27005 and integrates with the broader PIMS privacy risk assessment under clause 6.1 and the SDF DPIA under A.1.2.6 / section 10.

The asset inventory

The asset inventory identifies the digital-PII surfaces in the PIMS scope. The categories: PII-bearing systems (databases, applications, APIs); PII in transit (every network path); PII at rest (every storage medium); PII in logs; PII in backups; PII on endpoints; PII in the SDLC; PII in outsourced development. The inventory reconciles to the ROPA.

The threat catalogue

The threats to the digital-PII assets include: the unauthorised read (the SQL injection; the insider query; the over-permissioned service account); the unauthorised write (the tampering with the PII record; the consent-record manipulation); the exfiltration (the bulk export; the staged exfiltration through low-and-slow queries); the ransomware encryption; the key compromise (the KMS breach; the credential leak); the backup-tape loss; the log integrity failure (the log manipulation; the log overwriting before the retention expired); the SDLC gap (the PII-bearing release that shipped without the privacy sign-off); the outsourced-development gap (the vendor's breach; the vendor's retention of PII after the engagement).

The vulnerability catalogue

The vulnerabilities include: the encryption gap (the unencrypted backup; the unencrypted log; the unencrypted non-production copy); the authentication gap (the password-only application; the shared service-account; the MFA gap on internal tools); the logging gap (the PII table without access logging; the log with plaintext PII; the retention below 180 days); the SDLC gap (the threat model that does not identify PII; the release gate without the privacy sign-off); the architecture gap (the flat network; the secrets in source code); the vendor gap (the outsourced-development contract without the PII clauses).

The risk-treatment plan

The risk-treatment plan selects the controls from the A.3 Technological family (and the broader A.3 family) to treat each risk. The treatment options follow the ISO/IEC 27005 pattern: avoid (do not collect the PII in the first place; A.1.4.5 minimisation); transfer (the outsourced-development contract transfers the development risk under the DPA); mitigate (the encryption, the authentication, the logging, the SDLC); accept (with documented justification for the low-residual-risk items). The risk-treatment plan feeds the Statement of Applicability under clause 6.1.3.

Audit and Compliance Checklist

The Singahi A.3 Technological-family checklist (toolkit doc 04) covers 25 audit questions across the ten controls and the integration layer. The questions below are the recommended minimum examination set.

A.3.22, User endpoint devices

1. Is the MDM-managed endpoint posture enforced (full-disk encryption; 5-minute screen-lock on laptops and 1-minute on mobile; remote-wipe capability) across every endpoint that may hold PII locally? Expected: the MDM configuration; the device-level evidence. Red flag: no MDM; or MDM in place but the configuration is uneven; or BYOD devices without MDM.
2. Is the application allow-listing and DLP agent deployed to block PII egress to USB and unauthorised cloud storage? Expected: the DLP configuration; the egress-block evidence. Red flag: no DLP; or DLP deployed but policies not configured.
3. Is the off-boarding device-wipe performed when an employee leaves or when the processor's contract ends (A.2.4.3)? Expected: the off-boarding wipe record. Red flag: off-boarding without a wipe.

A.3.23, Secure authentication

4. Is MFA enforced on every PII-bearing session (customer-facing application; internal customer-support tool; engineer's production access; administrator's cloud-account access)? Expected: the MFA configuration; the session-level evidence. Red flag: MFA on the customer app but not on the internal tool; or shared service-account passwords in use.
5. Is the password policy aligned to NIST SP 800-63B (length minimum 12; breach-history check; no forced rotation; no complexity rules)? Expected: the policy; the breach-history check evidence. Red flag: the legacy policy (8 characters with forced quarterly rotation).
6. Are credentials stored salted and hashed with a memory-hard function (bcrypt, scrypt, argon2)? Expected: the credential-storage configuration. Red flag: plaintext; reversible encryption; weak hash (MD5, SHA-1 without salt).

A.3.24, Information backup

7. Are PII-bearing backups encrypted with a separate key (the backup key not the production-database key)? Expected: the backup-encryption configuration; the key-separation evidence. Red flag: unencrypted backups; or backups encrypted with the production key.
8. Is the offline or immutable backup slice maintained for ransomware resilience? Expected: the WORM target; the offline carousel. Red flag: no offline slice; the controller's only recovery path is paying the ransom.
9. Does the restoration-test cadence (typically quarterly) include a PII-restoration verification? Expected: the restoration-test records. Red flag: restoration tests skipped; or restoration tests without the PII verification.

A.3.25, Logging

10. Is every PII read transaction logged (who, what, when, from where)? Expected: the log configuration on the PII tables; the sample log entry. Red flag: the PII table without access logging.
11. Are the logs aggregated to a SIEM with at least 180-day retention within Indian jurisdiction? Expected: the SIEM configuration; the retention setting. Red flag: logs in siloed systems with 30-day retention.
12. Is the log content sanitised (no plaintext PII)? Expected: the log-sanitisation configuration; the sample log entry. Red flag: the application log that captures the full request body including the PII payload.
13. Are the time stamps NTP-synced per the CERT-In Directions? Expected: the NTP configuration. Red flag: time stamps not synced; log-integrity questions.

A.3.26, Use of cryptography

14. Is the PII encryption inventory documented and reconciled to the ROPA? Expected: the inventory; the reconciliation. Red flag: no inventory; or inventory not reconciled.
15. Is PII at rest encrypted everywhere it lives (production, non-production, backups, logs, caches) with AES-256 (or equivalent)? Expected: the encryption inventory; the per-location evidence. Red flag: PII encrypted only in the production database.
16. Is PII in transit encrypted with TLS 1.2 minimum (TLS 1.3 preferred) everywhere, including internal east-west traffic? Expected: the TLS configuration; the certificate inventory. Red flag: self-signed certificates on internal PII-bearing APIs; no mTLS for service-to-service east-west.
17. Is the key-management lifecycle documented (generation; rotation; storage; escrow; destruction) and operated through a KMS or HSM? Expected: the KMS or HSM configuration; the key-custodian-separation evidence. Red flag: keys in source code; in CI/CD variables; in configuration files in plaintext.
18. Is the crypto-shredding pattern applied for end-of-life PII where row-level deletion is infeasible? Expected: the crypto-shredding records. Red flag: no crypto-shredding pattern; the section 8(7) erasure duty unmet for backed-up data.

A.3.27 / A.3.28 / A.3.29, SDLC, application security, architecture

19. Does the SDLC integrate the privacy-by-design checklist at every stage (requirements, design, build, test, release)? Expected: the SDLC documentation; the per-release privacy-by-design artefacts. Red flag: a 27001-template SDLC with no privacy overlay.
20. Does the threat model identify PII as a Crown Jewel asset and catalogue the PII threats? Expected: the threat-model document. Red flag: threat model that does not identify PII.
21. Is the release gate enforced (no PII-bearing release ships without the privacy sign-off)? Expected: the release-gate configuration; the per-release sign-offs. Red flag: release gate exists but is bypassable or routinely bypassed.
22. Are the architectural patterns enforced (segmentation; PAM; secrets in vault; cloud-region discipline)? Expected: the architecture review records; the PAM deployment; the vault deployment. Red flag: flat network; shared service-account; secrets in source code; PII stored in the wrong cloud region.

A.3.30, Outsourced development

23. Do the outsourced-development contracts carry the PII clauses (secure-development standards; privacy-by-design checklist; secure-coding training; right-to-audit; sub-contractor disclosure; cross-border dimension; breach-notification SLA; no-retention-after-engagement)? Expected: the contract (toolkit doc 10). Red flag: vendor on a purchase order with no security or privacy clauses.
24. Are the vendor's sub-contractors disclosed and the changes notified in advance? Expected: the sub-contractor list; the change-notification records. Red flag: undisclosed sub-contractors; unnotified changes.

The breach-response dimension

25. Are the cryptographic-incident scenarios (key compromise; database breach; ransomware; backup-tape loss; log integrity failure) included in the incident response plan, with the dual-clock pattern? Expected: the scenarios in the playbook (toolkit doc 08); the drill records. Red flag: the incident response plan silent on the technological-incident scenarios; or the dual-clock pattern missing.

Metrics and KPIs

The Singahi A.3 Technological-family KPI set (toolkit doc 11) covers the ten controls and the integration dimension. The thirteen KPIs below are the recommended minimum.

PII inventory and encryption KPIs

1. PII inventory currency, the percentage of PII-bearing systems in the inventory reconciled to the ROPA. Target: 100%. Frequency: quarterly. Owner: DPO with Engineering.
2. PII-at-rest encryption coverage, the percentage of PII-bearing storage locations (production, non-production, backups, logs, caches) encrypted with AES-256 (or equivalent). Target: 100%. Formula: (encrypted locations / total locations) × 100. Frequency: quarterly. Owner: CISO.
3. PII-in-transit encryption coverage, the percentage of PII-bearing network paths encrypted with TLS 1.2 (or higher). Target: 100%. Frequency: quarterly. Owner: CISO.

Authentication and access KPIs

4. MFA enforcement coverage, the percentage of PII-bearing sessions (customer-facing; internal; production; administrator) with MFA enforced. Target: 100%. Frequency: monthly. Owner: CISO.
5. Shared service-account count, the count of shared service-account passwords on PII-bearing systems. Target: zero. Frequency: monthly. Owner: CISO.

Logging KPIs

6. PII-access logging coverage, the percentage of PII tables with access logging configured. Target: 100%. Frequency: quarterly. Owner: CISO.
7. Log retention attainment, the percentage of access logs retained for at least 180 days within Indian jurisdiction. Target: 100%. Frequency: monthly. Owner: CISO.
8. Log-content sanitisation attainment, the percentage of application logs with the sanitisation pattern applied (no plaintext PII). Target: 100%. Frequency: quarterly. Owner: Engineering.

Backup and key-management KPIs

9. Backup encryption coverage, the percentage of PII-bearing backups encrypted with a separate key. Target: 100%. Frequency: quarterly. Owner: CISO.
10. Restoration-test attainment, the count of restoration tests in the period against the planned cadence, with the PII-restoration verification included. Target: 100%. Frequency: quarterly. Owner: IT Lead.
11. Key rotation attainment, the percentage of data-encryption keys rotated per the documented cadence. Target: 100%. Frequency: annually. Owner: CISO.

SDLC and vendor KPIs

12. Privacy-gate enforcement, the percentage of PII-bearing releases that passed the privacy sign-off at the release gate. Target: 100%. Frequency: per release. Owner: Application Security Lead with DPO.
13. Outsourced-development contract currency, the percentage of outsourced-development engagements with the PII clauses in the contract. Target: 100%. Frequency: annually. Owner: Procurement Lead with DPO.

Incident KPI

14. Technological-incident dual-clock notification attainment, the percentage of technological-origin personal-data breaches in the period notified to CERT-In within six hours and to the DPBI without delay, with a detailed report within seventy-two hours. Target: 100%. Frequency: per incident. Owner: CISO / DPO.

Common Pitfalls and Audit Failures

The most common A.3 Technological-family audit findings in the Indian growing-company segment, in rough descending order of frequency.

The "we encrypt the production database" gap

The production database is encrypted; the non-production copy is not; the backup is not; the log captures plaintext PII; the cache is not encrypted. The encryption discipline is partial. Fails A.3.26 read with the inventory discipline. Remediation: the PII encryption sprint (Section 1, Quick Win); the encryption inventory reconciled to the ROPA.

The self-signed certificate on the internal PII-bearing API

The customer-facing application has a proper certificate; the internal API between the application and the database (or between the application and the analytics service) uses a self-signed certificate; the certificate-management discipline is absent. Fails A.3.26 read with the in-transit dimension. Remediation: the certificate inventory; the automated renewal; the mTLS deployment for service-to-service east-west.

The shared service-account password

The customer-support PII application uses a shared service-account password (the "support-user" account with the password known to all agents). The authentication layer is effectively bypassed; the logging layer attributes every action to the shared account; the breach response is impossible (the audit trail cannot distinguish one agent from another). Fails A.3.23 and A.3.25. Remediation: per-user authentication; the service-account in the secrets manager with just-in-time elevation.

The MFA gap on the internal tool

The customer sees MFA; the internal customer-support tool does not. The internal tool is the higher-risk surface (the agent has bulk access to the customer base; the customer has access only to their own data). Fails A.3.23. Remediation: MFA enforced on every PII-bearing session, including internal.

The application log that captures plaintext PII

The application log captures the full request body for debug purposes; the request body contains the PII payload. The log was meant to be the evidence base; the log has become the secondary PII surface (and the secondary breach surface). Fails A.3.25 read with the log-content dimension. Remediation: the log-sanitisation pattern; the PII fields masked in the log entry.

The secrets in source code

The database password is in the source code (or in the CI/CD variable, or in the configuration file in plaintext). The source code is in the version-control system; the version-control system is accessible to the engineering team; the engineering team includes the contractor in another country. Fails A.3.29 read with the secret-management dimension. Remediation: the secrets in the vault; the access policy enforced; the rotation cadence operated; the secrets-scanning deployed.

The unencrypted backup tape

The backup tape carousel stores the PII-bearing backup; the backup is unencrypted; the tape is in a third-party data vault. The tape's loss or theft is the canonical section 8(6) breach, and the canonical section 8(5) failure (the confidentiality dimension). Fails A.3.24 and A.3.26. Remediation: the backup-encryption discipline with a separate key; the offline or immutable slice for ransomware resilience.

The SDLC without the privacy gate

The SDLC has a security gate (the penetration test before the major release); there is no privacy gate. The PII-bearing release ships without the privacy sign-off; the threat model does not identify PII; the test cases do not verify the PII protection. Fails A.3.27 / A.3.28. Remediation: the privacy-by-design checklist integrated into every stage; the release gate enforced.

The outsourced-development vendor on a purchase order

The vendor is engaged on a purchase order with no security or privacy clauses; the vendor's engineers have direct production access; the vendor's sub-contractors are undisclosed; the vendor's location is in a country on the (future) DPDP negative list. Fails A.3.30. Remediation: the Outsourced Development Security Schedule (toolkit doc 10); the contract clauses flowed down; the sub-contractor list disclosed; the cross-border screen operated.

The log retention below 180 days

The default log retention in the application's log driver is 30 days; the SIEM's default is 90 days; the CERT-In 180-day baseline is not met. The breach investigation that needs the 6-month-old access record cannot be performed. Fails A.3.25 read with the CERT-In Directions. Remediation: the 180-day retention configured; the retention aligned to the longer of the CERT-In baseline, the A.1.4.8 retention schedule, and the sector-regulator baseline.

The flat network

The corporate network and the production network are not segmented; the engineer's laptop (which may be compromised) can reach the production database directly. Fails A.3.29. Remediation: the segmentation; the production network reachable only through the application layer with authentication and authorisation.

The restoration test skipped

The backup is taken on schedule; the restoration test is skipped (the "we'll do it next quarter" pattern). When the ransomware hits, the controller discovers the backup is corrupted or the restoration procedure does not work. Fails A.3.24. Remediation: the restoration-test cadence (quarterly at minimum); the PII-restoration verification included.

The "we bought a tool, so we are done" trap

The KMS, the SIEM, the SDLC platform, the backup platform are deployed; the configurations are not done; the operational discipline is absent. The tools are check-boxes, not operational disciplines. Fails the operational-effectiveness test across the family. Remediation: configure the tools; run the operational cadence; measure the KPIs.

Illustrative Scenario 1: Failure, Northbound Fintech and the Unencrypted Backup Tape (Illustrative)

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome. It is set after 13 May 2027, when the DPDP Act's duties and the Board's inquiry and penalty powers take effect.

Disclaimer: This is an illustrative scenario developed for educational purposes. The company name is fictional; the patterns are drawn from the publicly documented audit-failure patterns of multiple Indian fintech and digital-lending platforms. No specific real company is described.

The platform processes identity data (PAN, Aadhaar last-4, photo, address), financial data (salary slips, bank statements, credit-bureau pulls), payment data (repayment-instrument tokens) and behavioural data (the loan-application journey).

The A.3 Technological architecture at the audit. At the time of the breach in late 2027, Northbound's tech architecture was typical of an Indian growing-company fintech that had prioritised product velocity over security-engineering depth. The production database (a managed Postgres in an Indian-region cloud account) was encrypted at rest with the cloud-provider default. The non-production copy (used by the analytics team for monthly reporting) was a snapshot of production, unencrypted and accessed by a shared analytics service account. The PII-bearing backup was the managed-backup service's daily snapshot, encrypted with the production-database key (not a separate key). The application log captured the full request body for debug purposes; the request body contained the PII payload. The internal customer-support tool (a CRM with full customer-record access) had password-only authentication; MFA was on the customer-facing app but not on the internal tool. The outsourced development vendor (a 40-engineer firm in another Indian city) had direct production access through a shared service-account.

The trigger. In November 2027, the off-site backup-tape vendor (a third-party data vault in Maharashtra) reported that one of the monthly tapes was missing from the carousel, lost in transit between the cloud region's tape-export facility and the vault. The tape contained the previous month's PII-bearing backup, approximately 2.8 million customer records, encrypted with the production-database key (which was, in turn, protected by the cloud-KMS in the same cloud account).

The investigation. Northbound's incident-response team was activated within hours. The team's first analysis: the tape was almost certainly misplaced rather than stolen (the carrier's tracking showed a warehouse sorting error). But the absence of physical control of the tape for an indeterminate window meant the controller had to assume the PII was potentially exposed. The encryption status was the canonical mitigation, except that the backup key and the KMS protecting it were in the same cloud account, and a sophisticated attacker who obtained the tape might also target the cloud account.

The dual-clock failure. Northbound became aware of the missing tape on 8 November 2027. The CERT-In six-hour clock was missed (the security team treated the missing tape as a "logistics issue" rather than a cyber incident; the CERT-In report was filed on day 4). The DPDP breach clock (intimation without delay; seventy-two-hour report) was missed (the DPO was looped in on day 3; the Board notification was filed on day 6). The affected customers were notified in tranches through December 2027.

The regulatory outcome. The Data Protection Board of India, on a complaint from a customer whose data was on the missing tape, opened an investigation in January 2028. The investigation found that Northbound's A.3 Technological operation did not meet DPDP section 8(5) (the unencrypted non-production copy; the shared analytics service account; the application log with plaintext PII; the MFA gap on the internal CRM; the shared service-account at the vendor), section 8(6) (the dual-clock failure), and the Schedule's SDF-readiness dimension (Northbound was on the cusp of SDF designation given the customer base). The DPBI imposed a penalty in the section 8(5) / section 8(6) band (in the range of INR 70 to 140 crore given the breach scale and the dual-clock failure), required remediation within six months, and required ongoing reporting for two years.

The lessons. The encryption discipline was partial; the inventory was absent; the application log was a secondary PII surface; the internal CRM was the higher-risk surface without MFA; the vendor's access was ungoverned; the dual-clock pattern was not drilled. Each gap was individually recoverable; the combination was the breach. An ISO/IEC 27701:2025 Stage 1 audit conducted six months earlier would have surfaced all six gaps.

Illustrative Scenario 2: Success, Madhuram Health Insurance Builds the PII-Aware Tech Layer (Illustrative)

Disclaimer: This is an illustrative scenario developed for educational purposes. The company name is fictional; the patterns are drawn from the publicly documented remediation programmes of multiple Indian health-insurance and health-tech platforms. No specific real company is described.

The setting. Madhuram Health Insurance Company Limited (MHICL) is a standalone health insurer in India, approximately 4.6 million policyholders, gross written premium of approximately INR 6,200 crore, regulated by the IRDAI. MHICL processes member identity data (PAN, Aadhaar last-4, photo), health data (the pre-existing-condition declaration; the claims history; the diagnostic reports), financial data (premium payment; claims payment) and operational data (the call-centre recording; the branch-CCTV footage).

The pre-remediation state. In early 2026, ahead of the DPDP Rules' full-enforceability window, MHICL's A.3 Technological architecture was uneven. The core insurance platform (the policy administration system, the claims system) was well-disciplined (decades of IRDAI regulation had driven encryption and access-control maturity). The digital-engagement layer (the customer app, the agent portal, the telemedicine integration) was less mature, the customer app had MFA but the agent portal did not; the analytics environment held an unencrypted copy of the claims data; the application log on the claims API captured the full request body including the diagnostic-report reference.

The trigger. MHICL's board, on the recommendation of the newly-appointed DPO (a role created in late 2025 ahead of an expected SDF-equivalent designation under IRDAI's enhanced expectations for health insurers), decided in March 2026 to seek ISO/IEC 27701:2025 certification ahead of the DPDP Rules' full-enforceability window (estimated May 2027). The decision was driven by three considerations: (i) IRDAI's enhanced technology expectations for health insurers; (ii) the planned launch of an AI-assisted claims-triage feature that would consume health PII at scale; (iii) the enterprise customer segment (group-health policies) was increasingly asking for ISO/IEC 27701 attestation in procurement.

The remediation programme (April 2026 to January 2027). The DPO structured the programme in three quarters.

Quarter 1, Inventory and quick wins. The team ran the PII encryption sprint across the multi-cloud estate. The inventory identified 38 PII-bearing storage locations (production, non-production, backup, log, cache, analytics warehouse). The sprint closed 11 encryption gaps (the unencrypted analytics copy; the unencrypted non-production snapshot; the unencrypted backup on the legacy tape carousel; the application log without sanitisation; the cache without encryption; and others). The team adopted the Singahi Technological-Controls Gap Analysis (toolkit doc 12).

Quarter 2, Key management, authentication, logging. The team deployed the cloud-KMS with key-custodian separation (the analytics-service key distinct from the production key; the backup key distinct from the production key; the high-sensitivity PII, health data, biometric data, under an HSM-backed key). MFA was extended to every PII-bearing session (the agent portal; the underwriter's tool; the claims-operations dashboard; the administrator's cloud-account access). The application logs were sanitised; the SIEM aggregation was extended to the digital-engagement layer; the 180-day retention was verified end-to-end. The shared service-accounts were retired; per-user authentication with just-in-time elevation through the PAM platform replaced them.

Quarter 3, SDLC integration, outsourced development, drill. The team integrated the privacy-by-design checklist (toolkit doc 03) into the SDLC at requirements, design, build, test and release. The release gate, no PII-bearing release ships without the privacy sign-off, was enforced in the CI/CD pipeline. The outsourced development vendor base (12 vendors, primarily the AI-claims-triage vendor, the telemedicine integration vendor, and the customer-app development vendor) was re-papered with the Outsourced Development Security Schedule (toolkit doc 10). The cryptographic-incident drill, tabletop in month 8; full drill in month 10, traced the dual-clock pattern: the simulated key-compromise scenario; the CERT-In six-hour clock met (the report was filed in 4 hours and 50 minutes); the DPDP breach clock (intimation without delay; seventy-two-hour report) met (the Board notification was filed in 38 hours); the IRDAI incident-reporting clock met.

The certification outcome. Stage 1 audit in December 2026 passed with two minor nonconformities (the certificate-expiry monitoring was point-in-time rather than continuous; the restoration-test cadence on the legacy tape carousel was semi-annual rather than quarterly). Both were closed before Stage 2 in January 2027. The Stage 2 audit sampled four recent PII-bearing releases (the customer-app release; the agent-portal release; the claims-API release; the telemedicine-integration release), walked the encryption inventory end-to-end, walked the key-management records, walked the access-log for a sample principal's data, and walked the outsourced-development contracts. Zero major nonconformities on the Technological family.

The return.

• Avoided penalty exposure. The pre-remediation pattern carried estimated DPDP penalty exposure of approximately INR 110 to 220 crore (the unencrypted analytics copy of health PII; the MFA gap on the agent portal; the application log with plaintext PII; the shared service-account; the ungoverned vendor access). The remediation reduced the exposure by an estimated 90%.
• Operational efficiency. The PAM platform removed the shared service-account pattern (an estimated 220 person-hours per quarter of manual access provisioning); the SIEM extension produced a measurable improvement in mean-time-to-detect (from approximately 14 hours to approximately 90 minutes).

The lessons. Treat the Technological family as a risk-reduction investment, not a compliance cost. The PII encryption sprint is the highest-use quick win. The KMS deployment with key-custodian separation is the load-bearing architectural decision. The SDLC integration is the discipline that prevents the next PII-bearing release from creating the next gap. The drill makes the dual-clock pattern survivable.

Multi-Framework Mapping

The detailed crosswalk

The DPDP-section-to-Technological-family map (load-bearing for India)

The DPDP Act section-by-section Technological-family hooks: section 8(5) (reasonable security safeguards, covers encryption, authentication, logging, backup; the load-bearing Indian anchor; penalty up to INR 250 crore); section 8(6) (breach notification, the dual-clock pattern triggered by the cryptographic incident; the encryption status as the canonical mitigation; penalty up to INR 150 crore); section 8(7) (erasure, the crypto-shredding pattern); section 10 (SDF, the DPO, SDF DPIA, independent audit, algorithmic-software review); section 11 (controller-processor contract, the development-vendor dimension); section 16 (cross-border, the cloud-region and key-custody dimension); section 33 + Schedule (penalties); the IT Act section 43A (legacy safeguards) and section 72A (criminal liability for disclosure).

The sector-regulator overlay (India-specific)

The Indian statutory-anchoring summary

The Technological family maps onto the DPDP Act in three dense clusters. Cluster 1, cryptography, authentication, logging (A.3.23, A.3.25, A.3.26): anchored in section 8(5) safeguards (the load-bearing Indian anchor), section 8(6) breach-notification (the encryption status as mitigation), and section 8(7) erasure (the crypto-shredding pattern). Cluster 2, endpoint, backup, architecture (A.3.22, A.3.24, A.3.29): anchored in section 8(5) safeguards (the confidentiality, integrity and availability dimensions) and section 16 cross-border (the cloud-region and key-custody dimension). Cluster 3, SDLC, application security, outsourced development (A.3.27, A.3.28, A.3.30): anchored in section 8(5) safeguards (the by-design dimension), section 11 controller-processor contract (the development-vendor flow-down), and section 10 SDF (the algorithmic-software overlay where ML consumes PII). A controller or processor that implements the Technological family has implemented the technology core of the DPDP Act's safeguards duty.

Implementation Roadmap

The Singahi 30 / 90 / 180-day implementation roadmap (toolkit doc 05) for the A.3 Technological family.

The first 30 days, inventory and quick wins

• Day 1 to 5, Sponsor and team. The DPO confirms executive sponsorship (the CEO or the CTO for a growing company; the board for an enterprise) and convenes the cross-functional team (DPO, CISO, Head of Engineering, Application Security Lead, Procurement Lead).
• Day 6 to 15, PII inventory. The team inventories every PII-bearing surface (production, non-production, backups, logs, caches, endpoints, SDLC, vendor engagements) with the encryption status, the authentication posture, the logging posture, the backup posture attached. The inventory reconciles to the ROPA.
• Day 16 to 25, Anti-pattern audit. The team audits each surface against the anti-pattern library (the unencrypted backup; the self-signed certificate; the shared service-account; the MFA gap on the internal tool; the application log with plaintext PII; the secrets in source code; the flat network; the vendor on a purchase order).
• Day 26 to 30, Quick wins. The team implements the top-three highest-risk remediations (typically: the PII encryption sprint; the MFA extension to the internal tool; the secrets-vault deployment).

The 90-day milestone, KMS, logging, MFA

• Day 31 to 50, Key management. The team deploys the cloud-KMS or HSM with key-custodian separation; the encryption keys are migrated to the KMS; the rotation cadence is documented.
• Day 51 to 70, Logging. The team extends the PII-access logging to every PII table; the application logs are sanitised; the SIEM aggregation is extended; the 180-day retention is verified.
• Day 71 to 90, MFA and authentication. The team extends MFA to every PII-bearing session; the shared service-accounts are retired; the PAM platform is deployed for the privileged accounts.

The 180-day milestone, SDLC, vendor, drill

• Day 91 to 120, SDLC integration. The team integrates the privacy-by-design checklist into the SDLC; the release gate is enforced; the threat-model template is deployed.
• Day 121 to 150, Outsourced development. The team re-papers the outsourced-development vendor base with the Security Schedule (toolkit doc 10); the sub-contractor lists are disclosed; the cross-border screens are operated.
• Day 151 to 180, Drill and KPIs. The team runs the cryptographic-incident drill (tabletop then full drill); the dual-clock pattern is traced. The thirteen KPIs (Section 12) are rolled out.

The 9-to-12-month arc, full Technological-family maturity

• Month 7, Internal audit. The team runs the internal audit (Clause 9.2) covering the Technological family. The findings are closed before the certification Stage 1.
• Month 8, Management review. The team reports the KPIs to the management review (Clause 9.3).
• Month 9 to 10, Certification Stage 1 and Stage 2. The certification Stage 1 documentation review; the Stage 2 operational-effectiveness test.

The ongoing cadence (post-certification)

• Weekly, KPI dashboard review; SIEM alert triage; access-log spot-check.
• Monthly, MFA coverage review; shared-account count review; certificate-expiry review; restoration-test scheduling.
• Quarterly, PII inventory reconciliation; encryption coverage review; restoration test (with the PII-restoration verification); key rotation review.
• Annually, full cryptographic-incident drill; Technological-family policy review; vendor-contract review.

FAQ

Q1. We already have an ISO/IEC 27001 certificate. Does that mean A.3 Technological is automatically covered?

No, and this is the most common 2025-edition misread. The 2025 edition is standalone-certifiable; a separate 27001 certificate is no longer a prerequisite. But the A.3 Technological controls must still be implemented within the PIMS scope. The 27001 evidence base is useful cross-reference material; the PIMS auditor will re-examine it for the PII-protection overlay (the encryption inventory, the access-log sanitisation, the SDLC privacy gate) that a generic 27001 audit does not test.

Q2. A.3.26 says "use of cryptography". What is the minimum standard for PII?

The Singahi recommended minimum: AES-256 (or equivalent) for PII at rest; TLS 1.2 minimum (TLS 1.3 preferred) for PII in transit; tokenisation or field-level encryption for high-sensitivity PII at scale. Keys generated, stored, rotated and destroyed through a KMS or HSM; key-custodian separation enforced. Self-signed certificates on PII-bearing APIs are not acceptable; the certificate-management discipline is enforced.

Q3. Our application log captures the full request body for debug purposes. The request body contains PII. Is that a problem?

Yes. The application log has become a secondary PII surface, and a secondary breach surface. The log-content sanitisation pattern (mask the PII fields in the log entry; log the field names or hashed references; never log payloads) is the operational discipline. The log was meant to be the evidence base; the log must not become the next breach.

Q4. We use a shared service-account password for the customer-support PII application because per-user authentication is operationally expensive. Is that acceptable?

No. The shared service-account is the canonical A.3.23 failure and the canonical A.3.25 failure, the authentication layer is bypassed; the logging layer attributes every action to the shared account; the breach response is impossible. Per-user authentication is operationally feasible; the PAM platform with just-in-time elevation is the standard pattern.

Q5. Our backup is encrypted with the production-database key. Is that sufficient?

It depends. If the production-database key is in the same KMS as the backup key (or worse, the same key), the compromise of the KMS compromises both the production and the backup. The Singahi recommended pattern is the separate backup key in a separate KMS (or, for the highest-sensitivity PII, in an HSM), the compromise of one does not compromise the other. Key-custodian separation is the architectural pattern.

Q6. The vendor for our customer app is in a foreign country. What should we do?

Run the cross-border screen under DPDP section 16 (any country restriction notified under section 16(1)) and the equivalent in any other applicable jurisdiction (GDPR Chapter V for EU personal data; the destination country's data-protection regime). The vendor's engineering location and the vendor's access to the controller's PII engage the section 16 dimension. The contract (toolkit doc 10) carries the cross-border clauses; the access architecture may need to be re-engineered (the vendor's engineers work in a non-PII environment; the production PII never leaves the Indian region).

Q7. How often should we run the cryptographic-incident drill?

Annually for growing companies; semi-annually for mid-sized (250 to 2,000) and enterprise; semi-annually plus tabletop exercises between for SDFs under DPDP section 10. The drill traces the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks where applicable). The scenarios: the key compromise; the database breach; the ransomware event with PII at stake; the backup-tape loss; the log integrity failure.

Q8. Our outsourced development vendor says their ISO/IEC 27001 certificate covers A.3.30. Is that sufficient?

It depends. The vendor's 27001 certificate evidences their ISMS posture; it does not flow the controller's PII-specific obligations down. The Singahi recommended pattern: rely on the vendor's 27001 for the security baseline, but layer the A.3.30 PII clauses (the privacy-by-design checklist; the secure-coding training; the right-to-audit; the sub-contractor disclosure; the breach-notification SLA; the cross-border dimension; the no-retention-after-engagement) on top through the Security Schedule (toolkit doc 10).

Q9. What is crypto-shredding and when should we use it?

Crypto-shredding is the erasure technique whereby the encryption key protecting a data set is destroyed, rendering the ciphertext unrecoverable. Use it where row-level deletion is operationally infeasible (the backed-up PII across multiple snapshots; the replicated PII across multiple regions; the cached PII across multiple layers). The destruction of the key, with the documented destruction record (the key identifier; the destruction timestamp; the responsible individual; the verification), is the controller's evidence that the DPDP section 8(7) erasure duty was met.

Q10. We are a SaaS processor for our customer controllers. Do the A.3 Technological-family controls apply to us?

Yes, A.3 applies to both PII controllers and PII processors. The Technological-family scope covers your services that process customer personal data under the customer controller's instructions. Your DPA with the customer should flow down the Technological-family requirements; your supplier agreements (for sub-processors) should flow them further.

Q11. The CERT-In 180-day log retention mandate, does it apply to the application access log?

Yes, where the application access log captures information relevant to the prescribed cyber incidents (unauthorised access; data breach; ransomware). The 180-day baseline applies to the access logs of the PII-bearing systems, within Indian jurisdiction. Longer retention is permissible and often advisable for the high-sensitivity PII zones (the audit trail that the principal's rights request needs may go back further than 180 days; align the retention to the longer of the CERT-In baseline, the A.1.4.8 retention schedule, and the sector-regulator baseline).

Q12. We are an Indian subsidiary of a foreign parent. Whose Technological-family framework applies?

Both, layered. The parent's framework typically sets the global baseline; the Indian subsidiary's framework adds the DPDP dimension (the encryption expectations; the key-custody-in-India dimension; the cloud-region discipline; the CERT-In 180-day retention). The Singahi recommended pattern is a single global Technological-family framework with Indian-specific overlays. Document the layering; the auditor tests both.

Industry-Specific Requirements

BFSI (banking, financial services, insurance)

BFSI is the most prescriptively technology-regulated Indian sector. The load-bearing instruments: RBI Digital Lending Guidelines (2 Sep 2022); RBI Storage of Payment System Data (6 Apr 2018), payment-data localisation extends to the cloud-region and the key-custody dimension; RBI Card-On-File Tokenisation (2021–22), the tokenisation mandate for card data; SEBI CSCRF (20 Aug 2024), the 6-hour incident-reporting clock and the technology expectations for SEBI Regulated Entities; IRDAI Information and Cyber Security Guidelines (24 Apr 2023), the technology controls for insurers and ICT-outsourcers. Technological-family emphasis for BFSI: the payment-data localisation dimension; the tokenisation pattern for card data; the key-custody-in-India dimension; the BFSI-grade cryptographic-incident drill with the sector-regulator clocks alongside CERT-In and DPDP.

Healthcare

Healthcare carries the highest-sensitivity PII (the diagnostic data; the pre-existing-condition data; the mental-health data; the reproductive-health data) and the IRDAI overlay for insurers. Technological-family emphasis for healthcare: the field-level encryption for health PII; the tokenisation for the diagnostic-data exchange between providers and insurers; the strict access-control for the mental-health and reproductive-health data; the audit trail that supports the patient's rights request; the cyber-insurance dividend available to the disciplined operator.

IT-ITeS and SaaS

The IT-ITeS and SaaS sector operates as the processor for hundreds of customer controllers, each with its own A.3 Technological expectations. Technological-family emphasis for IT-ITeS and SaaS: the multi-tenant architecture that isolates each customer's PII; the encryption-with-customer-controlled-keys pattern (the customer holds the key; the processor cannot read the PII without the customer's instruction); the per-customer logging and audit trail; the cross-border dimension (the offshore development centre; the cross-border remote engineer); the customer-audit dimension (the customer's right to audit the processor's A.3 Technological implementation).

E-commerce and retail

E-commerce processes high-volume customer PII (identity, contact, payment, behavioural). Technological-family emphasis for e-commerce: the customer-app's authentication (MFA on the customer session); the payment-data localisation (the RBI Storage of Payment Data dimension); the application-level rate-limiting (PII enumeration prevention); the DLP on the customer-support floor (the bulk-export prevention); the breach-response readiness given the high-volume high-visibility surface.

Edtech

Edtech processes children's data (the DPDP section 9 overlay, verifiable parental consent; the heightened safeguards duty). Technological-family emphasis for edtech: the verifiable-parental-consent dimension in the technology architecture (the consent record tied to the parent's identity; the withdrawal mechanism wired to the data-deletion flow); the strict access-control for the children's data; the breach-notification dimension for children's data (the section 9 penalty exposure, up to INR 200 crore).

Manufacturing

Manufacturing's PII surface is smaller but concentrated (the employee data; the supplier-contact data; the customer-PII on the warranty / service side). Technological-family emphasis for manufacturing: the OT-IT convergence (the operational-technology systems that hold PII on the shop floor, the access-control systems; the biometric devices; the contractor-management systems); the legacy-system dimension (the older manufacturing-execution systems with weaker security posture); the vendor-management dimension (the large contractor base).

Maturity Model

Figure · Tiers

Maturity levels for technological controls

Level 1, Initial / Ad-hoc

Characteristics. No Technological Controls Policy. The encryption discipline is partial (production database only). The internal tool has no MFA. The shared service-account is in use. The application log captures plaintext PII. The backup is unencrypted. The SDLC has no privacy gate. The outsourced-development vendor is on a purchase order. The cryptographic-incident drill has never been run. The CERT-In 180-day retention is not met.

Investment to reach L1. None, this is the floor.

Covers the PII inventory, the gap analysis, the Technological Controls Policy, the PII encryption sprint scoping, the KMS / HSM architecture design, the SDLC privacy-gate design.

Level 2, Repeatable / Defined

Characteristics. A documented Technological Controls Policy. A current PII inventory reconciled to the ROPA. The PII encryption sprint closed on production; the non-production and backup gaps documented. The KMS deployed with key-custodian separation. The MFA extended to every PII-bearing session. The shared service-accounts retired. The SDLC privacy-gate designed. The outsourced-development vendor base mapped.

Covers the encryption extension to non-production, backups, logs, caches; the SIEM extension with 180-day retention; the SDLC privacy-gate deployment; the outsourced-development re-papering; the first cryptographic-incident drill.

Level 3, Managed / Measured

Characteristics. The encryption inventory complete and reconciled. The SIEM-aggregated PII-access logging with 180-day retention. The MFA across every PII-bearing session. The SDLC privacy gate enforced in the CI/CD pipeline. The outsourced-development vendors under the Security Schedule. The cryptographic-incident drill run annually (semi-annual for mid-sized organisations, 250 to 2,000). The thirteen KPIs reporting; the first management-review pack produced.

Covers the field-level encryption or tokenisation for the highest-sensitivity PII; the HSM-backed key management; the predictive analytics on the SIEM; the cross-border remote-engineer dimension; the algorithmic-software overlay where ML consumes PII; the semi-annual drill programme.

Level 4, Quantitatively Managed

Characteristics. The field-level encryption or tokenisation operating for high-sensitivity PII. The HSM-backed key management with custodian separation. The SIEM with anomaly detection and behavioural analytics. The cross-border dimension operated under DPDP section 16. The SDF DPO-led Technological-family programme (where the controller is an SDF). The cryptographic-incident drill running semi-annually with the dual-clock pattern met across CERT-In, DPDP and the sector-regulator clocks. The KPI programme operating with predictive analytics.

Level 5, Optimising

Characteristics. The privacy-engineering practice is a continuous engineering discipline (every new PII-bearing feature triggers the privacy-by-design checklist at design; every release passes the privacy gate; every new vendor carries the Security Schedule). The Technological-family architecture is integrated with the broader privacy-engineering practice (the encryption is wired to the PII inventory; the logging is wired to the rights-request flow; the SDLC is wired to the ROPA). The cryptographic-incident drill is run quarterly with multi-incident scenarios. The KPI programme produces board-level dashboards with trend analysis and predictive insights.

Maturity-model quick-reference

Emerging Trends

The DPDP Rules' phased commencement

The DPDP Rules 2025 (notified 13 November 2025) phase in through 2026 and 2027. The Technological-family-relevant slices include the breach-notification format (Rule 7 intimation) that the cryptographic incident triggers, the SDF dimension (the SDF DPIA that triggers the architectural assessment), and the verifiable-parental-consent dimension for edtech. Controllers and processors that build the Technological-family discipline ahead of the full-enforceability window (estimated May 2027) will have a two-to-three-year advantage over those that retrofit.

The tokenisation shift for high-sensitivity PII

The RBI Card-On-File Tokenisation framework (2021–22) was the leading edge of a broader tokenisation shift in the Indian market. The emerging pattern: tokenise high-sensitivity PII (card data, health data, biometric data) at the point of collection, store the token in the operational systems, and store the underlying PII only in a controlled vault with the de-tokenisation flow under strict access control. The breach of the operational systems exposes tokens, not PII; the breach impact is materially lower.

The convergence of security engineering and privacy engineering

The two disciplines, historically separate, are converging in the enterprise engineering practice. The driver: the privacy-by-design commitment (A.1.4 controller-side; A.3.27 / A.3.28 / A.3.29 tech-side) requires the same engineering discipline that the security-by-design commitment requires (threat modelling, secure coding, test cases, release gates). The Singahi recommended pattern is a single engineering practice with two dimensions, the security threat-model and the privacy threat-model alongside each other; the security test cases and the privacy test cases alongside each other; the security gate and the privacy gate at the same release gate.

The algorithmic-software overlay

The Rule 13(3) algorithmic-software overlay is the leading edge of a broader convergence between privacy engineering and AI governance. The technological-family implications for ML systems that consume PII: the training-data minimisation (the least PII necessary for the model's purpose); the model-card discipline (the documentation of the model's data, the training process, the known limitations); the bias-testing (the regular evaluation of the model's outputs for disparate impact across protected categories); the explainability dimension (the principal's right to understand the automated decision). The Singahi Layer 3 specialised curriculum for ML engineers already reflects this.

The post-quantum cryptography horizon

The post-quantum-cryptography (PQC) transition, driven by NIST's PQC standardisation process (FIPS 203, 204, 205 finalised in 2024), will, over the next decade, require every long-lived PII-bearing crypto deployment to be re-evaluated. The "harvest now, decrypt later" threat (the attacker who stores the encrypted PII today to decrypt it when the quantum computer arrives) engages the highest-sensitivity PII deployments first. The emerging practice is the PQC-readiness assessment (the crypto inventory extended with the algorithm's PQC-vulnerability status; the migration plan).

The cloud-region and key-custody dimension

The Indian data-localisation expectations (RBI Storage of Payment Data; any country restriction notified under DPDP section 16(1)) are extending to the key-custody dimension. The emerging pattern: the PII in the Indian region, the key in the Indian region (under Indian control), the cross-region replication engaged through the section 16 screen. The architectural implication is that the global multi-region cloud architecture must be re-evaluated for the Indian PII, the keys do not leave the Indian region even for the cross-region replication.

References and Further Reading

Standards and regulations

• ISO/IEC 27701:2025, Privacy information management system, Requirements and guidance (published 14 October 2025).
• ISO/IEC 27001:2022, Information security management systems, Requirements; Annex A.8 (Technological controls).
• ISO/IEC 27002:2022, Information security controls; theme 8 (Technological), controls 8.1, 8.5, 8.13, 8.15, 8.24, 8.25, 8.26, 8.27, 8.28, 8.31.
• ISO/IEC 27040:2024, Storage security.
• ISO/IEC 18033 (all parts), Encryption algorithms.
• ISO/IEC 27017:2015, Code of practice for cloud security.
• ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor.
• ISO/IEC 29100:2011, Privacy framework.
• ISO/IEC 29134:2017, Guidelines for privacy impact assessment.
• ISO/IEC 27706:2025, PIMS certification-scheme competence (Ed 1, October 2025; replaces ISO/IEC TS 27006-2:2021).
• ISO/IEC 17021-1:2015, Management-system certification-body requirements.
• ISO/IEC 27006 (current edition), ISMS certification-body requirements.

Indian regulatory instruments

• Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023, enacted 11 August 2023; eGazette notification 247847). Source: meity.gov.in.
• Digital Personal Data Protection Rules, 2025 (notified 13 November 2025; phased commencement). Source: meity.gov.in.
• Information Technology Act, 2000 (Act No. 21 of 2000), sections 43A and 72A. Source: indiacode.nic.in.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (notified 11 April 2011).
• CERT-In Directions No. 20(3)/2022-CERT-In (28 April 2022) under section 70B(6) of the IT Act, 2000. Source: cert-in.org.in.
• RBI, Digital Lending Guidelines, RBI circular DOID.CO.PPG.SEC.09/14.14.001/2022-23 (2 September 2022). Source: rbi.org.in.
• RBI, Storage of Payment System Data, RBI circular DPSS.CO.OD.No.1098/06.08.005/2017-18 (6 April 2018). Source: rbi.org.in.
• RBI, Card-On-File Tokenisation framework (guidelines issued 2021; extended and enforced 2022). Source: rbi.org.in.
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF) 2024, circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 August 2024). Source: sebi.gov.in.
• IRDAI, Information and Cyber Security Guidelines, 2023 (24 April 2023). Source: irdai.gov.in.

Jurisprudence

• 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 of India).
• Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 (26 September 2018, five-judge Bench).

Global regulations (mapped in Section 16)

• Regulation (EU) 2016/679 (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1; application from 25 May 2018. Source: eur-lex.europa.eu. Article 5(1)(f) (integrity and confidentiality), Article 25 (data protection by design and by default), Article 32 (security of processing), Article 33 (breach notification, 72 hours).
• UK GDPR; Data Protection Act 2018 (c. 12).
• California Consumer Privacy Act / California Privacy Rights Act (Cal. Civ. Code 1798.100 et seq.).
• Brazil, LGPD (Lei nº 13.709/2018).
• China, PIPL, effective 1 November 2021.
• Singapore, PDPA 2012 as amended.
• Canada, PIPEDA (S.C. 2000, c. 5).
• Australia, Privacy Act 1988; Australian Privacy Principles.
• South Korea, PIPA.

Frameworks and guidance

• NIST Privacy Framework v1.0: A Tool for Improving Privacy Through Enterprise Risk Management, NIST.CSWP.01162020 (16 January 2020). Source: nist.gov/privacy-framework. Identify-P; Protect-P (data security).
• NIST SP 800-57 Part 1 Rev 5, Recommendation for Key Management.
• NIST SP 800-63B, Digital Identity Guidelines (Authentication and Lifecycle Management).
• NIST SP 800-218, Secure Software Development Framework (SSDF).
• NIST SP 800-160, Systems Security Engineering.
• NIST SP 800-88 Rev 1, Guidelines for Media Sanitisation (referenced for the A.3 Physical disposal dimension).
• NIST FIPS 140-3, Cryptographic Module Security Requirements.
• NIST FIPS 203 / 204 / 205, Post-Quantum Cryptography Standards (2024).
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (TSC 2017; 2022 Points of Focus update).
• OWASP Application Security Verification Standard (ASVS).
• OWASP Top 10; OWASP API Security Top 10.
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification.

Certification-scheme and practitioner references (generic)

• IAF (International Accreditation Forum), note: no PIMS-specific IAF MD identified as of mid-2026.
• Accreditation bodies active in PIMS: ANAB, UKAS, DAkkS, COFRAC, JAB, CNAS, and others.
• The certification-scheme rule-set: ISO/IEC 17021-1:2015; ISO/IEC 27006; ISO/IEC 27706:2025.