Generates Records of Processing Activities automatically from IT system inventories including Active Directory, cloud service catalogs, API gateway logs, and database schemas. Covers automated field population, data flow discovery, and system-to-RoPA mapping. Activate for automated RoPA, system inventory, data discovery, auto-population, IT-driven records.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Generates Records of Processing Activities automatically from IT system inventories including Active Directory, cloud service catalogs, API gateway logs, and database schemas. Covers automated field population, data flow discovery, and system-to-RoPA mapping. Activate for automated RoPA, system inventory, data discovery, auto-population, IT-driven records.
Manual RoPA creation through interviews and questionnaires is time-consuming, subjective, and prone to omitting processing activities that stakeholders forget or are unaware of. Automated RoPA generation leverages existing IT system inventories, cloud service catalogs, API gateway logs, and database schemas to discover processing activities and pre-populate Art. 30(1) fields. This approach reduces the RoPA creation burden by 60-80% while improving coverage, as it captures processing activities that manual interviews routinely miss (shadow IT, automated data pipelines, third-party integrations).
Data Sources for Automated RoPA Population
Source 1: Active Directory / Azure AD
What it reveals:
Organisational structure (departments, teams) for mapping processing owners
Group memberships revealing who has access to what systems (recipient categories)
Application registrations and service principals (processing system inventory)
Which APIs handle personal data (based on request/response inspection)
Data flow patterns between systems (upstream and downstream)
Third-party API integrations (external recipients)
Volume and frequency of data processing (helps assess whether processing is "occasional" for Art. 30(5))
API Gateway analysis for Helix Biotech Solutions:
API Endpoint
Method
Personal Data Fields
Upstream System
Downstream System
Daily Volume
/api/v2/employees
GET/POST
employee_id, name, email, department
SAP SuccessFactors
Internal HR portal
340 requests
/api/v2/patients/{id}/records
GET
patient_id, diagnosis, treatment
Veeva Vault CDMS
Clinical reporting dashboard
1,200 requests
/api/v2/orders
POST
customer_name, email, billing_address
Salesforce
SAP ERP
890 requests
/api/v1/analytics/events
POST
ip_address, user_agent, page_url
Website (JS tracker)
Google Analytics
45,000 requests
/api/v2/vendor/payments
POST
vendor_name, bank_account, tax_id
SAP ERP
Banking API (Deutsche Bank)
120 requests
Source 4: Database Schemas
What it reveals:
Exact data categories stored (column names and types)
Table relationships revealing data flows
Personal data identification through column name pattern matching
Data volume and growth patterns
Schema analysis approach:
Connect to each database identified in the cloud catalog.
Extract table schemas (column names, data types, constraints).
Apply personal data identification patterns to column names.
Map identified personal data columns to Art. 30(1)(c) data categories.
Personal data column name patterns:
Pattern
Data Category
Art. 9 Special Category
*name*, *first_name*, *last_name*, *full_name*
Name
No
*email*, *e_mail*
Email address
No
*phone*, *mobile*, *telephone*
Phone number
No
*address*, *street*, *city*, *postcode*, *zip*
Postal address
No
*dob*, *date_of_birth*, *birth_date*
Date of birth
No
*ssn*, *social_security*, *tax_id*, *national_id*
National identifier
No
*salary*, *compensation*, *bank_account*, *iban*
Financial data
No
*ip_address*, *ip_addr*
IP address
No
*diagnosis*, *medical*, *health*, *condition*
Health data
Yes
*genetic*, *dna*, *genome*
Genetic data
Yes
*biometric*, *fingerprint*, *facial*
Biometric data
Yes
*ethnicity*, *race*, *ethnic_origin*
Racial/ethnic origin
Yes
*religion*, *religious*, *belief*
Religious beliefs
Yes
*union*, *trade_union*
Trade union membership
Yes
*political*, *party*
Political opinions
Yes
*criminal*, *conviction*, *offence*
Criminal data (Art. 10)
Art. 10
Automated Field Population Logic
Art. 30(1)(a) — Controller Identity
Source: Azure AD tenant configuration + organisation management.
Automation: Fully automated from AD tenant metadata.
Art. 30(1)(b) — Purposes
Source: Application descriptions in AD enterprise application registry + API documentation.
Automation: Partially automated. The system name and description provide a starting point, but specific purpose articulation requires human refinement to meet Art. 5(1)(b) specificity requirements.
Approach: Generate a draft purpose from the application description, flag it as "DRAFT — requires DPO review," and assign to the processing owner for refinement.
Art. 30(1)(c) — Data Subject and Data Categories
Source: Database schema analysis + API request/response schemas.
Automation: Highly automated for data categories (column name matching). Data subject categories require inference from table context.
Art. 30(1)(d) — Recipients
Source: AD security groups (internal recipients) + API gateway logs (external integrations) + cloud service catalog (processors).
Automation: Highly automated. AD groups reveal internal access. API gateway reveals external data flows. Cloud catalog identifies processors.
Art. 30(1)(e) — International Transfers
Source: Cloud service region configuration + API gateway destination IPs + CDN configuration.
Automation: Highly automated. If a cloud service is deployed in a non-EEA region, or API calls route to non-EEA endpoints, the system flags a potential international transfer.
Art. 30(1)(f) — Retention Periods
Source: Database table statistics (oldest records), backup retention policies, lifecycle management rules.
Automation: Partially automated. Can detect actual retention (how long data exists) but not intended retention (how long it should exist). Flags discrepancies between actual and policy retention.
False positives in PII detection: Column names like "company_address" may be flagged as personal data when they are business data. Mitigation: human review of all auto-detected PII columns.
Missing context for purposes: Automated systems cannot infer the business purpose of processing from technical metadata alone. Mitigation: purposes are always flagged as "DRAFT" and require human articulation.
Shadow IT blind spots: Systems not registered in AD or cloud catalogs will not be discovered. Mitigation: combine automated discovery with periodic manual questionnaires to capture unregistered processing.
Encrypted or tokenised data: If data is encrypted at the column level or tokenised, schema analysis may not detect personal data. Mitigation: maintain a manual register of encryption/tokenisation mappings.
Consent and lawful basis: Cannot be determined from technical metadata. Always requires legal/DPO input.
