Overview
Create the PIMS Statement of Applicability covering both Annex A (controller) and Annex B (processor) controls from ISO 27701. The SoA maps each control to an In/Out decision with specific justification, implementation status, and evidence references — serving as the PIMS-specific equivalent of the ISO 27001 SoA. For organizations acting in dual roles (both controller and processor), the SoA covers both annexes; for single-role organizations, the non-applicable annex is explicitly scoped out with justification. The PIMS SoA extends but does not replace the ISO 27001 SoA, and it is built from the controller and processor controls registers produced by companion skills.
What It Covers
- Annex A Controls (Controller) — 31 controller control objectives from A.7.2 (conditions for collection and processing) through A.7.5 (PII sharing, transfer, and disclosure)
- Annex B Controls (Processor) — 18 processor control objectives from B.8.2 (conditions for processing) through B.8.5 (PII sharing, transfer, and disclosure)
- In/Out Decisions — Explicit applicability decision for every control with specific, defensible justification (not generic “N/A”)
- Implementation Status — Tracking each included control through Not Started, Planned, Implemented, and Verified stages
- Evidence Mapping — Linking each applicable control to specific policies, procedures, contracts, or system configurations
- Cross-Register Consistency — Validation that SoA decisions align with controller and processor controls register statuses
Example Conversation
You: We need to create the PIMS Statement of Applicability for MedSecure Health Technologies. We act as both a controller (patient engagement portal, marketing website, job applications) and a processor (SaaS platform for hospital clients). We’ve already completed the controller and processor controls registers.
Agent: Since MedSecure operates in a dual role, the PIMS SoA will cover both Annex A (31 controller controls) and Annex B (18 processor controls) — that is 49 controls total. Let me load your controller and processor controls registers to build the SoA.
From the controller controls register, I can see 28 controls are Implemented, 2 are Partially Implemented (A.7.3.10 automated decision-making and A.7.2.7 joint PII controller), and 1 is Not Applicable (A.7.2.7 joint controller — with justification that MedSecure has no joint controller arrangements).
From the processor controls register, all 16 documented controls are Implemented with evidence.
I’ll now build the SoA. For the Annex A controls marked Partially Implemented, I’ll set their SoA status to “In” with “Planned” implementation status. For A.7.2.7 (joint PII controller), the register marks it N/A — should this be “Out” in the SoA?
You: Yes, we have no joint controller arrangements. A.7.2.7 should be Out. Also, A.7.3.10 on automated decision-making — we’re implementing a risk scoring feature in the engagement portal that will use automated processing. It’s in development now, so mark it as Planned with a target date of Q3 2026.
Agent: Understood. I’ll mark A.7.2.7 as “Out” with the justification “MedSecure does not operate as a joint controller with any other organization. All controller processing activities are under MedSecure’s sole controllership.” And A.7.3.10 will be “In” with status “Planned” and the Q3 2026 target.
I’ve written the complete PIMS SoA. Let me validate completeness and consistency.
check_pims_soa_completenessonoutput/PIMS-Statement-of-Applicability.md:=== PIMS SoA COMPLETENESS CHECK === --- SCOPE --- Annex A (controller): In scope Annex B (processor): In scope --- ANNEX A (CONTROLLER) --- Total controls: 31 Included (In): 30 Excluded (Out): 1 Missing: 0 With evidence: 28/30 With implementation status: 30/30 --- ANNEX B (PROCESSOR) --- Total controls: 18 Included (In): 18 Excluded (Out): 0 Missing: 0 With evidence: 18/18 With implementation status: 18/18 --- COMBINED --- Total controls: 49 Included: 48, Excluded: 1, Missing: 0 With evidence: 46/48 With implementation status: 48/48 Errors: 0, Warnings: 2Two warnings: the Planned controls (A.7.3.10, A.7.4.6) lack evidence references since they are not yet implemented. That is expected. Now checking consistency against the registers.
check_pims_soa_consistencyon the SoA with both registers:=== PIMS SoA CONSISTENCY CHECK === Consistency score: 100% (47/47 checks passed) Overall: SoA is consistent with controls registers. Errors: 0, Warnings: 0The SoA is complete and fully consistent with both controls registers. All 49 controls are addressed with no contradictions.
Sample Output Excerpt
Below is a representative excerpt from the PIMS Statement of Applicability showing both Annex A and Annex B control entries for MedSecure’s dual-role implementation.
PIMS Statement of Applicability — MedSecure Health Technologies
Organization: MedSecure Health Technologies Ltd. PIMS Scope: SaaS health data platform — dual role (controller and processor) Date: 2026-03-21 Version: 1.0 Approved by: Chief Information Security Officer
Scoping Decision
MedSecure acts as both a PII controller (patient engagement portal, marketing website, job applications, CRM) and a PII processor (SaaS platform processing hospital client data). Both Annex A and Annex B are in scope.
Annex A — Controller Controls
| Control ID | Title | Applicable | Justification | Status | Evidence |
|---|---|---|---|---|---|
| A.7.2.1 | Identify and document purpose | In | Processing purposes documented in PII inventory for all 4 controller activities. Privacy policy Section 2 maps each activity to its purpose. | Implemented | PII-Inventory.md, Privacy-Policy.md Section 2 |
| A.7.2.2 | Identify lawful basis | In | Legal basis identified per activity: consent (engagement portal, marketing), pre-contractual (job applications), legitimate interest (CRM). | Implemented | PII-Inventory.md, Privacy-Policy.md Section 3 |
| A.7.2.5 | Privacy impact assessment | In | DPIA program established with WP29 screening criteria. Two DPIAs completed for high-risk activities. | Implemented | DPIA-Methodology.md, DPIA-Register.md |
| A.7.2.7 | Joint PII controller | Out | MedSecure does not operate as a joint controller with any other organization. All controller processing activities are under MedSecure’s sole controllership. No joint controller agreements exist. | N/A | — |
| A.7.3.6 | Access, correction and/or erasure | In | Self-service portal for data subject requests. Manual process via DPO for non-account holders. 30-day response SLA (GDPR), 15-day (LGPD). | Implemented | DSR-Procedure-v2.1.pdf, Privacy-Policy.md Section 7 |
| A.7.3.10 | Automated decision making | In | Risk scoring feature for engagement portal under development. Target: Q3 2026. Will include opt-out mechanism and human review on request. | Planned | Feature spec RS-2026-Q3, Privacy-Policy.md Section 10 |
Annex B — Processor Controls
| Control ID | Title | Applicable | Justification | Status | Evidence |
|---|---|---|---|---|---|
| B.8.2.1 | Customer agreement | In | Standard DPA executed with all 14 hospital clients specifying subject matter, duration, nature of processing, and data categories. LGPD addenda for Brazilian clients. | Implemented | DPA-Template-v3.2.pdf, LGPD-Addendum-v1.1.pdf |
| B.8.2.6 | Records related to processing PII | In | Records of processing activities maintained per client, including data categories, recipients, retention, and transfers. Updated quarterly. | Implemented | ROPA-Q1-2026.xlsx, PII-Inventory.md |
| B.8.5.7 | Engagement of a subcontractor | In | Sub-processor onboarding requires security assessment, privacy screening, DPA execution, and DPO approval. Three sub-processors currently engaged (AWS, Twilio, CloudBR). | Implemented | Sub-Processor Assessment Checklist SAC-001 |
| B.8.5.8 | Change of subcontractor | In | Controllers notified 30 days before sub-processor changes. 15-day objection window. Alternative arrangements or penalty-free termination offered on objection. | Implemented | Change Notification Template CNT-001 |
Extension Tools
check_pims_soa_completeness
Validates that the PIMS Statement of Applicability covers all applicable Annex A and Annex B control objectives.
| Check | What It Validates |
|---|---|
| Annex scope detection | Determines whether Annex A (controller) and/or Annex B (processor) are in scope |
| Annex A coverage (31 controls) | Every controller control from A.7.2.1 through A.7.5.4 is present in the SoA |
| Annex B coverage (18 controls) | Every processor control from B.8.2.1 through B.8.5.8 is present in the SoA |
| In/Out decision | Each control has an explicit “Applicable” or “Not Applicable” designation |
| Justification for included controls | Included controls have substantive justification describing how they are met |
| Justification for excluded controls | Excluded controls have specific, defensible exclusion reasons (not generic “N/A”) |
| Evidence references | Included controls reference specific policies, procedures, or evidence documents |
| Implementation status | Included controls have a status: Not Started, Planned, Implemented, or Verified |
Returns coverage statistics (total controls, included, excluded, missing, with evidence, with implementation status) and severity-classified findings. Missing controls are flagged as errors; missing evidence and status are warnings.
check_pims_soa_consistency
Cross-references the PIMS SoA against the controller and processor controls registers to detect contradictions.
| Check | What It Validates |
|---|---|
| Implemented controls are “In” | Controls marked “Implemented” in registers appear as “In” in the SoA |
| N/A controls are “Out” | Controls marked “Not Applicable” in registers appear as “Out” in the SoA |
| Evidence alignment | “In” controls in the SoA have evidence references matching register documentation |
| No contradictions | No control is “Implemented” in a register but “Out” in the SoA (or vice versa) |
Accepts three paths: the SoA document, the controller controls register (optional for processor-only orgs), and the processor controls register (optional for controller-only orgs). Returns a consistency score (percentage of checks passed) and detailed contradiction list. Scores above 90% indicate good consistency.
Getting Started
The PIMS SoA is built from prerequisite skills. Prepare the following before starting:
Controller controls register — Run the ISO 27701 Controller Controls skill first. This provides the Annex A control implementation statuses and evidence that feed into the SoA.
Processor controls register — Run the ISO 27701 Processor Controls skill. This provides the Annex B control implementation statuses and evidence.
Role determination — Know whether your organization acts as a controller, processor, or both. This determines which annexes are in scope. If dual-role, both registers are needed.
ISO 27001 SoA — If your organization already has an ISO 27001 Statement of Applicability, have it available. The PIMS SoA extends (not replaces) the 27001 SoA, and consistency between the two is important.
Exclusion justifications — For any controls you plan to exclude, prepare specific justifications. Auditors reject generic “N/A” — you need defensible reasons like “no joint controller arrangements exist” or “no automated individual decision-making is performed.”
Start by telling the agent your organization’s role (controller, processor, or dual) and confirming that the prerequisite controls registers are complete. The agent will load both registers and build the SoA with In/Out decisions, then validate completeness and consistency.