ISO 27701 PIMS Workspace: From PII Scoping to Privacy Certification Readiness in 11 Steps

A practical guide for privacy consultants and DPOs on using Rakenne's ISO 27701 PIMS workspace template to build a complete, internally consistent Privacy Information Management System documentation set — with tool-assisted validation at every step.

intermediate
18 min read
2026-03-21
Skills

Author Ricardo Cabral · Founder

Building an ISO 27701-compliant Privacy Information Management System is documentation-heavy — and it sits on top of an already-complex ISO 27001 ISMS. A first-time PIMS implementation typically requires 3–6 months of additional consulting effort beyond the ISMS, with the hardest part being the granular PII processing inventory, the controller/processor control mapping, and ensuring every privacy policy claim traces back to an actual documented control.

Rakenne’s ISO 27701 PIMS workspace template provides 10 specialized skills and over 20 validation tools that guide an LLM agent through the full PIMS lifecycle. Each skill enforces a structured workflow, loads ISO 27701-specific references, and uses deterministic tools to check the agent’s output — catching the kinds of errors that plain LLM drafting misses: incomplete processing activity records, controller controls without evidence, privacy policies that claim rights coverage they don’t actually deliver, and cross-document inconsistencies where the PII inventory contradicts the privacy policy.

This guide walks through all 11 steps in sequence, shows real dialog excerpts and tool outputs from a live session, and explains what makes tool-assisted PIMS documentation materially better than generic AI drafting.

Why plain LLMs fall short for ISO 27701

A plain LLM can draft privacy policies, ROPA entries, and DPIA reports. Where it struggles is privacy-grade validation:

Concern	Plain LLM	Rakenne with ISO 27701 skills
PII inventory completeness	Can miss required fields (legal basis, retention, transfers)	Validates every processing activity has all 7 mandatory fields
Controller/processor traceability	Weak without structured state	Enforces links between PII inventory, Annex A/B controls, SoA, and privacy policy
Privacy policy–inventory consistency	Claims in policy may not match actual processing	Cross-checks every Clause 6 topic against the PII inventory and controller controls
Repeatable process	Output varies with prompt phrasing	Each skill defines a fixed workflow; same checks run every time
Self-correction	Model may claim coverage without delivering it	Validation tools return PASS/FAIL; the agent revises until checks pass

The difference is structural: skills give the agent a spec (workflow + references + structure) and tools (deterministic checks) to verify its own output. This is what turns a draft into an auditable artifact.

ISO 27701 extends ISO 27001 — and so does this workspace

ISO 27701 is not a standalone standard. It adds privacy-specific requirements on top of an existing ISMS. The workspace reflects this:

Three ISO 27001 skills are auto-installed as dependencies: Organization Profile, Risk Assessment, and Statement of Applicability. If you’ve already built your ISMS in the ISO 27001 workspace, the PIMS workspace reads those artifacts directly.
The PIMS skills add privacy-specific layers: privacy risk assessment (risks to PII principals, not just the organization), controller/processor controls (Clause 7 and 8), privacy policy generation (Clause 6), and DPIA procedures.
The dependency chain is enforced: you can’t run the DPIA program without first completing the PII inventory and privacy risk assessment. The workspace won’t let you skip steps.

The 11-step PIMS journey

The workspace template installs 10 PIMS-specific skills plus the shared Executive Readiness Report:

Phase	Step	Skill	What gets validated
Scope & Context	1	PIMS Scope	Role declaration, PII principal coverage, regulation identification, boundary completeness
Scope & Context	2	PII Inventory	Processing activity completeness (7 fields each), data flow consistency
Scope & Context	3	Privacy Risk Assessment	Privacy impact criteria (on individuals, not org), risk-to-principal coverage
Controls	4	Security Controls Overlay	Coverage of 16 key privacy-relevant controls across 4 themes
Controls	5	Controller Controls	Annex A coverage (A.7.2–A.7.5), implementation evidence
Controls	6	Processor Controls	Annex B coverage (B.8.2–B.8.5), sub-processor management
Validation	7	DPIA Program	Methodology completeness, WP29 screening criteria, DPIA entry coverage
Validation	8	Privacy Policy Generator	14 Clause 6 topics, privacy notice consistency
Audit	9	PIMS SoA	Annex A + B control coverage, cross-register consistency
Audit	10	PIMS Internal Audit	Audit plan completeness, finding classification, CAPA tracking
Audit	11	Executive Readiness Report	Board-ready compliance summary, readiness scoring

Each skill reads workspace files produced by earlier steps — the PIMS scope feeds into the PII inventory, the inventory feeds into controller/processor controls and the DPIA, the controls feed into the SoA, and the SoA feeds into the internal audit. The entire chain is traceable.

Step 1: PIMS Scope — establishing the privacy foundation

Every PIMS engagement starts with determining the organization’s role. Are you a PII controller (you decide why and how personal data is processed), a PII processor (you process data on behalf of a controller), or both? This determination shapes which Annex applies — Annex A for controllers, Annex B for processors — and which clauses of ISO 27701 are relevant.

The PIMS Scope skill captures this determination along with applicable regulations, PII principal categories, PIMS boundaries, and privacy objectives.

PIMS Scope

You: MedSecure Health Technologies is a 200-person health tech company based in São Paulo, with a London office for EU operations. We provide a SaaS platform that hospitals use to manage patient records. We also process employee HR data. We need to define our PIMS scope for ISO 27701 certification.
Agent: I’ll help define your PIMS scope. Let me start with the critical determination — your organization’s role.
Based on what you’ve described, MedSecure operates in a dual role:
PII Controller for: employee HR data (you determine purpose and means), marketing analytics, and your own customer relationship data
PII Processor for: patient health records processed on behalf of hospital clients (the hospitals are the controllers)
This means both Annex A (controller controls) and Annex B (processor controls) apply. Does this match your understanding?
You: Yes, exactly. We also have some clinical research partnerships where we anonymize data for research institutions.
Agent: Good — that adds a third processing context. Anonymization activities may fall under controller obligations since you’re determining the anonymization methodology. I’ll document this in the scope.
Now let me identify applicable regulations. Based on your locations and processing activities:
Regulation Trigger Applicability
LGPD (Brazil) HQ in São Paulo, employee data Applicable — all processing activities
GDPR (EU) London office, EU hospital clients Applicable — patient data, EU employee data
HIPAA (US) Health data processing Check — only if US hospital clients exist
ANPD Resolution 4 Health data under LGPD Applicable — sensitive data provisions
Do you have US hospital clients?
You: Not yet, but we’re planning to expand there next year.
Agent: I’ll note HIPAA as “planned applicability” in the scope. Now let me run the completeness check.
Running check_pims_scope_completeness…
Result: 6/6 sections covered:
Role declaration: PASS — dual role with justification
PII principals: PASS — 4 categories (patients, employees, hospital staff users, research participants)
Applicable regulations: PASS — 3 confirmed + 1 planned
PIMS boundaries: PASS — SaaS platform, HR systems, London office, anonymization pipeline
Privacy objectives: PASS — 5 objectives defined
Exclusions: PASS — marketing website analytics excluded with justification
The PIMS Scope Statement is saved and ready to feed into the PII inventory.

Regulation	Trigger	Applicability
LGPD (Brazil)	HQ in São Paulo, employee data	Applicable — all processing activities
GDPR (EU)	London office, EU hospital clients	Applicable — patient data, EU employee data
HIPAA (US)	Health data processing	Check — only if US hospital clients exist
ANPD Resolution 4	Health data under LGPD	Applicable — sensitive data provisions

The scope statement becomes the anchor for every subsequent step — the PII inventory only catalogs processing activities within the defined boundaries, the controller/processor controls only apply based on the declared role, and the privacy risk assessment focuses on the PII principals identified here.

Step 2: PII Inventory — the Record of Processing Activities

The PII Processing Inventory skill builds the ROPA — the foundational registry that GDPR Article 30 requires and that ISO 27701 uses as the basis for all control implementation. Every processing activity must document 7 mandatory fields: purpose, legal basis, data categories, PII principals, recipients, retention period, and cross-border transfer details.

PII Processing Inventory

You: Build the PII inventory based on our PIMS scope. We process patient records, employee HR data, hospital user accounts, and clinical research data.
Agent: I’ll catalog each processing activity. Let me walk through them one by one.
For patient health record processing (processor role):
What specific data categories do you process? (diagnoses, medications, lab results, imaging?)
Who receives the data beyond the hospital? (insurers, labs, other providers?)
What’s the contractual retention period?
You: We store diagnoses, medications, lab results, and patient demographics. Data stays within our platform — hospitals access it via API. Retention is 20 years per Brazilian health regulation (CFM Resolution 1821/2007), or as specified in each hospital’s DPA.
Agent: I’ve documented 4 processing activities. Let me run the validation tools.
Running check_pii_inventory_completeness…
Result: 4 processing activities found. Coverage:
Activity Purpose Legal Basis Categories Principals Recipients Retention Transfers
Patient records PASS PASS PASS PASS PASS PASS WARNING
Employee HR PASS PASS PASS PASS PASS PASS PASS
Hospital user accounts PASS PASS PASS PASS PASS PASS PASS
Clinical research PASS PASS PASS PASS WARNING PASS WARNING
Two warnings:
Patient records: cross-border transfers section is empty — do EU hospital clients’ data stay in Brazil or transfer to EU servers?
Clinical research: recipients list says “research institutions” without naming specific categories; transfer details missing for international research partnerships.
You: Patient data for EU hospitals is stored in our London GCP region. Research data is pseudonymized before sharing with institutions in Brazil and the EU.
Agent: Updated. Running check_data_flow_consistency to cross-check the data flow map…
Result: Consistency score: 95%. One finding: the data flow map shows a “backup replication” link to GCP us-east1, but no processing activity documents US data storage. I’ve added a note to the PII inventory documenting backup replication as a technical sub-processing activity with appropriate transfer safeguards (SCCs).
Re-check: PASS. All 4 activities fully documented, data flow map consistent.

Activity	Purpose	Legal Basis	Categories	Principals	Recipients	Retention	Transfers
Patient records	PASS	PASS	PASS	PASS	PASS	PASS	WARNING
Employee HR	PASS	PASS	PASS	PASS	PASS	PASS	PASS
Hospital user accounts	PASS	PASS	PASS	PASS	PASS	PASS	PASS
Clinical research	PASS	PASS	PASS	PASS	WARNING	PASS	WARNING

Here’s a sample from the PII inventory the agent produced:

Field	Patient Health Record Processing
Processing Activity	Storage, retrieval, and management of patient health records on behalf of hospital clients
Organization Role	PII Processor
Purpose	Enable hospital staff to manage patient care records through MedSecure’s SaaS platform
Legal Basis	Contract with controller (DPA with each hospital) — LGPD Art. 7(V), GDPR Art. 6(1)(b)
Data Categories	Patient demographics, diagnoses (ICD-10), medications, lab results, allergies, treatment history
PII Principals	Patients of hospital clients
Recipients	Hospital staff (via API), authorized healthcare providers (via interoperability interfaces)
Retention Period	20 years (CFM Resolution 1821/2007) or per hospital DPA, whichever is longer
Cross-Border Transfers	Brazil → EU (London GCP region for EU hospital clients); Brazil → US (backup replication, GCP us-east1, SCCs in place)

Step 3: Privacy Risk Assessment — risks to individuals, not just the organization

This is the fundamental shift from ISO 27001 to ISO 27701. In a standard ISMS risk assessment, the question is “what’s the impact on the organization?” In a privacy risk assessment, the question is “what’s the impact on the PII principal — the person whose data is being processed?”

The Privacy Risk Assessment skill enforces this distinction. Impact criteria must address individual harm — physical harm, financial loss, discrimination, reputational damage, emotional distress, identity theft — not just organizational consequences like regulatory fines or reputational damage to the company.

Privacy Risk Assessment

You: Assess privacy risks based on our PII inventory. Focus on the patient data and clinical research activities.
Agent: I’ve identified 8 privacy risks across the 4 processing activities. Let me show the patient data risks and run the validation.
ID Processing Activity Threat PII Principals L Privacy Impact Score Treatment
PR-01 Patient records Unauthorized access to health records Patients 3 5 (discrimination, denial of insurance) 15 Treat
PR-02 Patient records Data breach exposing diagnoses Patients 2 5 (stigmatization, emotional distress) 10 Treat
PR-03 Clinical research Re-identification of pseudonymized data Research participants 2 4 (loss of autonomy, surveillance) 8 Treat
PR-04 Employee HR Excessive collection beyond employment purpose Employees 3 3 (financial loss, discrimination) 9 Treat
Running check_privacy_impact_criteria…
Result: PASS. The methodology defines 6 privacy-specific impact categories: physical harm, financial loss, discrimination, reputational damage to individuals, emotional distress, and identity theft. These are distinct from organizational impact criteria — the assessment correctly focuses on harm to PII principals.
Running check_privacy_risk_completeness…
Result: 8 risks documented. All have: threat description, affected PII principals, likelihood, privacy impact score, risk level, and treatment decision. PII principal coverage: patients (3 risks), employees (2 risks), hospital staff (1 risk), research participants (2 risks) — all 4 principal categories from the PIMS scope are represented.

ID	Processing Activity	Threat	PII Principals	L	Privacy Impact	Score	Treatment
PR-01	Patient records	Unauthorized access to health records	Patients	3	5 (discrimination, denial of insurance)	15	Treat
PR-02	Patient records	Data breach exposing diagnoses	Patients	2	5 (stigmatization, emotional distress)	10	Treat
PR-03	Clinical research	Re-identification of pseudonymized data	Research participants	2	4 (loss of autonomy, surveillance)	8	Treat
PR-04	Employee HR	Excessive collection beyond employment purpose	Employees	3	3 (financial loss, discrimination)	9	Treat

Without the privacy impact criteria check, the agent could default to organizational impact metrics — “a breach costs us $2M in fines” instead of “a breach exposes patients to insurance discrimination and social stigma.” The tool enforces the ISO 27701 requirement that privacy risk assessment prioritizes impact on individuals.

Step 4: Security Controls Overlay — adding privacy to existing security controls

If you already have an ISO 27001 SoA, you don’t start from scratch. The Security Controls Overlay skill reads the existing SoA and adds a privacy augmentation layer. For each of the 93 ISO 27002:2022 controls, it documents what additional privacy-specific implementation is needed.

Security Controls Overlay

You: Create the privacy overlay for our existing SoA. We have 78 applicable controls.
Agent: I’ve reviewed all 78 applicable controls and identified privacy augmentations needed for 42 of them. Let me show a sample and run the validation.
Control Name Base Implementation Privacy Augmentation
A.5.12 Classification of information 3-level classification (Public, Internal, Confidential) Add PII sensitivity tiers: Standard PII, Sensitive PII (health data), Special category (Art. 9). Reclassify patient health records from Confidential to Sensitive PII.
A.8.11 Data masking Dynamic masking in staging/dev environments Extend to pseudonymization for clinical research outputs. Document pseudonymization techniques per LGPD Art. 13. Apply masking to all patient identifiers in non-production environments.
A.8.12 Data leakage prevention DLP rules for Confidential data in email/cloud Add PII-specific DLP rules: patient health identifiers, CPF numbers, diagnosis codes. Block bulk PII export without DPO approval.
Running check_controls_overlay_coverage…
Result: 4/4 themes covered. 14 of 16 key privacy-relevant controls have documented augmentations. 2 gaps:
A.5.34 (Privacy and protection of PII) — referenced but augmentation text is generic. I’ve expanded it with specific references to MedSecure’s PIMS scope and processing activities.
A.8.10 (Information deletion) — missing. I’ve added PII-specific deletion procedures: right to erasure workflows, retention period enforcement, and processor data return/destruction obligations.
Re-check: PASS. 16/16 key controls covered, 42 total augmentations documented.

Control	Name	Base Implementation	Privacy Augmentation
A.5.12	Classification of information	3-level classification (Public, Internal, Confidential)	Add PII sensitivity tiers: Standard PII, Sensitive PII (health data), Special category (Art. 9). Reclassify patient health records from Confidential to Sensitive PII.
A.8.11	Data masking	Dynamic masking in staging/dev environments	Extend to pseudonymization for clinical research outputs. Document pseudonymization techniques per LGPD Art. 13. Apply masking to all patient identifiers in non-production environments.
A.8.12	Data leakage prevention	DLP rules for Confidential data in email/cloud	Add PII-specific DLP rules: patient health identifiers, CPF numbers, diagnosis codes. Block bulk PII export without DPO approval.

Step 5: Controller Controls — Annex A obligations

The Controller Controls skill implements ISO 27701 Clause 7 and Annex A — the controls specific to organizations acting as PII controllers. For MedSecure, this covers employee HR data, customer relationship data, and the clinical research program where MedSecure determines the anonymization methodology.

Controller Controls

You: Implement the controller controls. Focus on the areas where we act as a controller — employee data, customer data, and clinical research.
Agent: I’ll walk through each Annex A control area. Let’s start with A.7.2 — Conditions for collection and processing.
For A.7.2.1 (Identify and document purpose): Each controller processing activity needs a documented purpose. From the PII inventory:
Employee HR: purpose is employment administration (documented)
Customer CRM: purpose is service delivery and contract management (documented)
Clinical research: purpose is medical research advancement through anonymized data (documented)
For A.7.2.2 (Identify lawful basis): Each purpose needs a legal basis:
Employee HR: Legal obligation (LGPD Art. 7(II)) + Contractual necessity
Customer CRM: Contractual necessity (LGPD Art. 7(V))
Clinical research: Consent of research participants (LGPD Art. 11(I))
Running check_controller_controls_coverage after documenting all 4 areas…
Result: Coverage: 21/23 Annex A controls documented.
A.7.2 (Collection/processing): 8/8 — PASS
A.7.3 (Obligations to PII principals): 8/10 — 2 gaps
A.7.4 (Privacy by design/default): 1/1 — PASS
A.7.5 (Sharing/transfer/disclosure): 4/4 — PASS
The 2 gaps in A.7.3:
A.7.3.9 (Handling requests): Documented but missing SLA for response time. I’ve added “30 days per LGPD Art. 18, 1 month per GDPR Art. 12(3).”
A.7.3.10 (Automated decision-making): Marked as N/A — justified since MedSecure doesn’t use automated decision-making for controller activities.
Re-check: PASS. 23/23 controls documented with status and justification.

Step 6: Processor Controls — Annex B obligations

The Processor Controls skill covers Clause 8 and Annex B — the controls for when MedSecure processes patient data on behalf of hospital clients. This is often the more complex side for health tech companies, because processor obligations include strict sub-processor management and data return/destruction procedures.

Processor Controls

You: Implement the processor controls for our hospital data processing activities.
Agent: Since MedSecure acts as a processor for patient health records, all Annex B controls apply. Let me walk through the key areas.
For B.8.2.1 (Customer agreement): Each hospital client must have a Data Processing Agreement. I’ll document the DPA framework — do all hospitals use your standard DPA template, or do some impose their own terms?
You: 80% use our template. Large hospital chains negotiate custom terms, especially around sub-processors and data residency.
Agent: Noted. For B.8.5.6 (Disclosure of sub-contractors): I need a list of sub-processors. From the organization profile and data flow map:
Sub-processor Service Data Access Location
GCP Infrastructure hosting All patient data Brazil (primary), EU (London), US (backup)
Datadog Monitoring Log data (may contain patient IDs in error logs) EU
SendGrid Email notifications Patient names in appointment reminders US
Running check_processor_controls_coverage…
Result: 15/16 Annex B controls documented. 1 gap:
B.8.5.8 (Change of sub-contractor): Procedure exists but missing the mandatory 30-day advance notice requirement for hospital clients. I’ve added the notification clause with a timeline aligned to GDPR Art. 28(2) and LGPD best practice.
Sub-processor management: PASS — 3 sub-processors documented with DPA status, data access scope, and location.
Re-check: PASS. 16/16 controls documented.

Sub-processor	Service	Data Access	Location
GCP	Infrastructure hosting	All patient data	Brazil (primary), EU (London), US (backup)
Datadog	Monitoring	Log data (may contain patient IDs in error logs)	EU
SendGrid	Email notifications	Patient names in appointment reminders	US

Step 7: DPIA Program — assessing high-risk processing

The DPIA Program skill establishes when Data Protection Impact Assessments are required, provides the methodology, and conducts DPIAs for high-risk activities. For a health data processor, several activities are likely to trigger DPIA requirements.

DPIA Program

You: Set up our DPIA program and assess which processing activities need DPIAs.
Agent: I’ll first establish the screening criteria, then screen each processing activity. The methodology follows WP29 Guidelines (now endorsed by EDPB) with 9 screening criteria. Activities meeting 2 or more criteria require a DPIA.
Screening results:
Activity Sensitive Data Large Scale Vulnerable Subjects Systematic Monitoring Score DPIA Required?
Patient health records Yes Yes Yes (patients) No 3 Yes
Clinical research (anonymization) Yes No Yes No 2 Yes
Employee HR No No Yes (employees) No 1 No
Hospital user accounts No No No No 0 No
Two activities require DPIAs. Let me conduct the first one — patient health record processing.
Running check_dpia_methodology…
Result: PASS. Methodology covers all required elements: 9 WP29 screening criteria, process steps, roles (DPO consultation required), escalation to supervisory authority threshold, review triggers.
Running check_dpia_completeness after completing both DPIAs…
Result: 2 DPIAs documented. Both have: processing description, necessity assessment, risks to individuals, mitigation measures, residual risk, DPO consultation. The patient records DPIA identified 4 residual risks, all mitigated to acceptable levels through encryption, access controls, and audit logging.

Activity	Sensitive Data	Large Scale	Vulnerable Subjects	Systematic Monitoring	Score	DPIA Required?
Patient health records	Yes	Yes	Yes (patients)	No	3	Yes
Clinical research (anonymization)	Yes	No	Yes	No	2	Yes
Employee HR	No	No	Yes (employees)	No	1	No
Hospital user accounts	No	No	No	No	0	No

Step 8: Privacy Policy Generator — Clause 6 compliance

The Privacy Policy Generator skill produces a privacy policy that maps directly to the 14 topics required by ISO 27701 Clause 6 for controllers. It reads the PII inventory and controller controls to ensure every claim in the policy is backed by actual documented controls — no aspirational statements.

You: Generate our privacy policy based on the PII inventory and controller controls.
Agent: I’ve drafted the privacy policy using the Clause 6 template and populated it from the PII inventory and controller controls register. Let me run the validation.
Running check_privacy_policy_clause6…
Result: Coverage: 13/14 topics (93%):
Topic Clause Status
Controller identity and contact 6.3.1 PASS
Purposes of processing 6.3.1 PASS
Legal basis per activity 6.3.1 PASS
Data categories 6.3.1 PASS
Recipients 6.3.1 / 6.5.3 PASS
International transfers 6.5.2 PASS
Retention periods 6.5.3 PASS
Access/rectification/erasure 6.7 PASS
Objection/restriction/portability 6.8 PASS
Consent and withdrawal 6.2.3 / 6.2.4 PASS
Automated decision-making 6.9.1 PASS
DPO contact 6.3.1 PASS
Complaints and supervisory authority 6.8 MISSING
Policy update notification 6.3.1 PASS
One critical gap: the complaints section doesn’t name the supervisory authority. For MedSecure, this should reference the ANPD (Brazil) and the ICO (UK) for EU operations. I’ve added both with contact details.
Running check_privacy_notice_consistency…
Result: Consistency score: 100%. All 3 processing purposes in the full policy appear in the condensed privacy notice. No contradictions detected.
Re-check of Clause 6: PASS — 14/14 topics covered.

Topic	Clause	Status
Controller identity and contact	6.3.1	PASS
Purposes of processing	6.3.1	PASS
Legal basis per activity	6.3.1	PASS
Data categories	6.3.1	PASS
Recipients	6.3.1 / 6.5.3	PASS
International transfers	6.5.2	PASS
Retention periods	6.5.3	PASS
Access/rectification/erasure	6.7	PASS
Objection/restriction/portability	6.8	PASS
Consent and withdrawal	6.2.3 / 6.2.4	PASS
Automated decision-making	6.9.1	PASS
DPO contact	6.3.1	PASS
Complaints and supervisory authority	6.8	MISSING
Policy update notification	6.3.1	PASS

Here’s a sample from the privacy policy the agent produced:

7. Data Retention

We retain personal data only for as long as necessary to fulfill the purposes described in this policy, or as required by law.

Processing Activity	Retention Period	Legal Basis for Retention
Employee HR records	Duration of employment + 5 years	LGPD Art. 16, CLT Art. 11 (labor statute of limitations)
Customer relationship data	Duration of contract + 3 years	Contractual necessity, legal obligation (civil code)
Clinical research data (anonymized)	Indefinite (fully anonymized data is no longer PII)	N/A — anonymized per LGPD Art. 12

When the retention period expires, personal data is securely deleted using the procedures documented in our Information Deletion Policy (Control A.8.10). You may request earlier deletion of your data by contacting our DPO (see Section 12 below), subject to legal retention obligations.

8. Your Rights

Under applicable data protection law, you have the following rights regarding your personal data:

Right of access — obtain confirmation of whether your data is processed and request a copy (LGPD Art. 18(II), GDPR Art. 15)
Right to rectification — correct inaccurate or incomplete data (LGPD Art. 18(III), GDPR Art. 16)
Right to erasure — request deletion when data is no longer necessary, consent is withdrawn, or processing is unlawful (LGPD Art. 18(VI), GDPR Art. 17)
Right to restrict processing — limit processing in specific circumstances (GDPR Art. 18)
Right to data portability — receive your data in a structured, machine-readable format (LGPD Art. 18(V), GDPR Art. 20)
Right to object — object to processing based on legitimate interest (GDPR Art. 21)

To exercise any of these rights, contact our Data Protection Officer at dpo@medsecure.com . We will respond within 15 days (LGPD) or 1 month (GDPR).

Step 9: PIMS Statement of Applicability — the unified control map

The PIMS SoA brings together everything from Steps 5 and 6 — controller controls (Annex A) and processor controls (Annex B) — into a single Statement of Applicability. For dual-role organizations like MedSecure, this is the document that auditors use to verify that both sets of obligations are addressed.

PIMS Statement of Applicability

You: Build the PIMS Statement of Applicability from our controller and processor controls registers.
Agent: Since MedSecure is both controller and processor, the PIMS SoA covers both Annex A (23 controls) and Annex B (16 controls) — 39 total. Let me cross-reference the registers and build the SoA.
Running check_pims_soa_completeness…
Result: 39/39 controls addressed:
Annex A: 22 In, 1 Out (A.7.3.10 Automated decision-making — justified, no automated decisions for controller activities)
Annex B: 16 In, 0 Out
With evidence: 35/38 applicable controls (92%)
Implementation status: Implemented 30, Planned 5, Not Started 3
Running check_pims_soa_consistency…
Result: Consistency score: 97%. One finding: Controller register marks A.7.5.2 (Countries for PII transfer) as “Implemented” with evidence, but the SoA has it as “Planned.” I’ve updated the SoA to match the register.
Re-check: PASS. Full consistency between both registers and the SoA.

Step 10: PIMS Internal Audit — testing the privacy program

The PIMS Internal Audit skill produces an audit plan, clause-by-clause checklist, findings report, and corrective action plan — all focused on privacy controls rather than general information security.

PIMS Internal Audit

You: Create the PIMS internal audit plan and conduct the audit against our documentation.
Agent: I’ve drafted the audit plan targeting PIMS Clauses 5–8 and both Annex A and Annex B controls. Lead auditor: external privacy consultant Ana Torres. Audit dates: April 7–11, 2026.
Running check_audit_plan_completeness…
Result: PASS. All required elements present: objectives, scope (Clauses 5-8, Annex A, Annex B), criteria (ISO 27701:2025), team (Ana Torres — confirmed independent from PIMS operations), schedule, and methodology.
I’ve completed the audit checklist and identified 4 findings:
Finding PIMS-NC-01 (B.8.5.7 Engagement of sub-contractor, Minor NC): Sub-processor DPAs exist for GCP and Datadog but the SendGrid DPA is unsigned — only a standard Terms of Service is on file.
Finding PIMS-NC-02 (A.7.3.6 Access/correction/erasure, Minor NC): Data subject request procedure exists but no log of requests received or processed. Cannot verify the procedure is operational.
Finding PIMS-OFI-01 (A.7.2.5 Privacy impact assessment, OFI): DPIAs were conducted for 2 high-risk activities, but the DPIA register doesn’t document the screening decision for the 2 activities that did not require DPIAs. Adding screening records would strengthen audit evidence.
Finding PIMS-OBS-01 (Clause 5.5 Support, Observation): Privacy awareness training materials are comprehensive and include LGPD/GDPR-specific modules — good practice noted.
Running check_audit_report_completeness…
Result: PASS. Report covers: executive summary, scope, methodology, 4 findings with correct classification, root cause analysis for both NCs, corrective action plans with owners and deadlines, and follow-up schedule.

Step 11: Executive Readiness Report — the board-level view

The Executive Readiness Report skill generates a board-ready compliance summary that distills the entire PIMS into a concise readiness scorecard. It aggregates data from all upstream artifacts — PIMS scope coverage, PII inventory completeness, controller/processor control coverage, DPIA completion, audit findings, and CAPA status — into a single document suitable for executive review and certification decision-making.

Cross-document traceability: the privacy auditor’s perspective

ISO 27701 auditors trace chains just like ISO 27001 auditors — but with a privacy lens. “Show me the processing activity. Show me the legal basis. Show me the controller control that implements it. Show me the privacy policy that discloses it to data subjects.” If one link breaks, the auditor writes a non-conformity.

Rakenne’s validation tools enforce these links automatically. Here’s what happens when the chain breaks:

Cross-Document Consistency

Agent: I’ve generated the privacy policy from the PII inventory. Running check_privacy_policy_clause6…
The Clause 6 topic checker found the privacy policy claims “processing based on legitimate interest” for employee monitoring, but the PII inventory lists the legal basis for employee HR processing as “legal obligation (CLT employment law).” These must be consistent.
I’ve updated the privacy policy to match the PII inventory’s legal basis. Running the check_privacy_notice_consistency tool to verify the condensed notice also matches…
Result: PASS. The privacy notice now correctly states “legal obligation” as the basis for employee data processing, consistent with both the PII inventory and the controller controls register.

This is the kind of inconsistency that survives weeks of manual review. A consultant might draft the privacy policy in February using “legitimate interest” (a reasonable choice), then in March the PII inventory is updated to “legal obligation” (a better fit for Brazilian employment law). Without automated cross-checking, the privacy policy stays wrong until an auditor catches it.

Getting started

Create a new project using the “ISO 27701 PIMS Implementation” template
If you already have an ISO 27001 ISMS workspace, the required foundation skills (Organization Profile, Risk Assessment, SoA) are auto-installed as dependencies
Start with the PIMS Scope skill — the agent will interview you about your organization’s PII processing context
Follow the sequence. Each skill builds on the previous one’s outputs

Have this information ready before you start:

Whether your organization is a PII controller, processor, or both (and for which activities)
A list of processing activities involving personal data
Which privacy regulations apply (GDPR, LGPD, CCPA, HIPAA, etc.)
Your technology stack and data storage locations
Key third-party processors and sub-processors
Any existing privacy documentation (policies, DPIAs, ROPA)

The workspace produces 15+ auditable documents: PIMS scope statement, PII processing inventory, data flow map, privacy risk assessment, controls overlay, controller/processor control registers, DPIA methodology and register, privacy policy, PIMS SoA, audit plan, audit report, and executive readiness report. Each one is cross-referenced, validated, and traceable.

Try it yourself

Open a workspace with the skills described in this article and start drafting in minutes.

Get Started Free — No Sign-Up