---
title: "How do you map privacy records to an RFP question?"
description: "Connect each buyer privacy proposition to the processing activity, responsible party, safeguard and current evidence that can support the answer."
canonical: "https://zephior.com/insights/map-privacy-controls-to-rfp-questions"
last-updated: 2026-09-04
---

# How do you map privacy records to an RFP question?

> Connect each buyer privacy proposition to the processing activity, responsible party, safeguard and current evidence that can support the answer.

By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-09-04; updated 2026-09-04. 20 minute read.

## Definition

A privacy requirement map is a procurement-specific record that links each testable part of a buyer question to one defined processing activity, the parties and people involved, the data lifecycle, the safeguards applied, and the evidence available for the offered service. It records a proposed controller, joint-controller or processor position as a review item rather than treating a sales label as law. It also separates a processing record, which describes what happens to personal data, from the policy, contract, configuration, operating record or assessment that may prove one part of the answer.

## Problem

A public buyer asks whether a recruitment platform acts only as a processor, minimizes applicant data, supports access and deletion requests, uses approved subprocessors and removes unsuccessful applications after the buyer's retention period. The proposal team finds a privacy policy, a record-of-processing entry and a standard data-processing agreement, then answers yes to the whole row. None of those documents alone shows whether product telemetry has a separate purpose, whether deleted applications survive in exports, how a rights request reaches backups, which messaging provider receives phone numbers, or whether the proposed edition supports the buyer's schedule. The documents exist, but the question still lacks a complete factual path.

## Point of view

Start with the exact buyer proposition and the processing that the proposed service will perform. Create a separate activity when purpose, role, data, people, recipient, retention or decision authority differs. Record the supplier's proposed role and the facts behind it, then leave the legal conclusion to the authorized privacy reviewer. Map every proposition to operational safeguards and evidence at the same service, configuration, data category and lifecycle stage. A policy can describe intent, a contract can allocate duties, a configuration can show a setting, and an operating record can show execution. None should borrow the proof value of another.

## Start with the proposed processing, not the privacy policy

Keep the question in its procurement context. Record the current document and clarification, exact wording, defined terms, lot, required answer format, requested attachment, evaluation use and date at which the statement must be true. “The supplier shall delete personal data” can describe a capability due at submission, a configured service at launch or an end-of-contract duty. The evidence and wording change with that event.

Fix the offer just as tightly. Name the bidder, contracting and operating entities, service and edition, enabled modules, tenant arrangement, integrations, identity source, regions, support tier, recovery design and relevant providers. A general privacy page can describe several products and optional functions. It cannot establish which processing will occur for this buyer.

Use the policy, processing register and standard agreement as inputs, then compare them with current product and operating facts. The CNIL describes a processing register as a view of actual activities, including purposes, people, data, recipients, retention and security. If the record does not match the offered configuration, the discrepancy is evidence to resolve, not a reason to repeat the record.

**Baseline fields for one privacy question**

| Area | Record | Failure prevented |
| --- | --- | --- |
| Buyer authority | Document, version, clause, definition, clarification and response field | Answering a replaced or incomplete question |
| Offer identity | Entity, service, edition, modules, tenant, region and support model | Combining incompatible product options |
| Processing boundary | Purposes, people, data, operations, recipients and lifecycle | Treating a system name as a data map |
| Required event | Submission, configuration, launch, operation or contract end | Calling a future behavior current |
| Review boundary | Factual owner, privacy reviewer, legal issue and disclosure class | Letting the response writer make the legal decision |

## Create a separate row for every material processing purpose

Describe activities, not applications. “Recruitment platform” is a system boundary. Candidate intake, interview scheduling, identity administration, support diagnosis, security monitoring, billing and product telemetry can be different activities. Split a row when purpose, affected people, data, recipient, retention, instruction or decision authority changes. This prevents one convenient processor label or retention period from spreading across unrelated operations.

Follow information from collection to final disposition. Include structured fields, uploaded documents, free text, messages, generated scores, audit events, search indexes, caches, exports, support copies, backups and restored data where they exist in the offered path. Mark data that never enters the supplier service. A truthful absence is as useful as a present category, provided the architecture or test supports it.

Keep legal basis and necessity as review fields rather than inventing them. The buyer may determine its legal basis for applicant processing. The supplier can provide accurate facts about product purpose, default fields, optional functions, access and deletion behavior. Privacy counsel then decides what those facts mean under the applicable regime and the buyer's own public duties.

**Minimum processing-activity row**

| Field | Example content | Why it matters |
| --- | --- | --- |
| Purpose | Schedule applicant interviews | Separates the intended use from adjacent operations |
| People | Applicants and interview panel members | Fixes whose rights and risks are in scope |
| Data | Identity, contact, availability and meeting metadata | Prevents a database name from hiding data categories |
| Operations | Collect, validate, display, notify, export, retain and erase | Makes the full lifecycle testable |
| Parties | Buyer, supplier entity, messaging provider and authorized users | Locates decisions, disclosures and dependencies |
| Disposition | Rule, trigger, active copies, backups, exports and exceptions | Turns “deleted” into a bounded claim |

## Record the role position and the facts that could change it

Do not derive role from the heading of a contract. The EDPB's final controller and processor guidance examines who determines purposes and essential means in the actual processing. A supplier can be a processor for customer-managed applicant records and have a different role for another activity it performs for its own purpose. Preserve the activity-level facts instead of forcing one label across the relationship.

For each purpose, record who decides why the processing occurs, which data and people are essential, how long information is needed, who may receive it, and which instructions the supplier accepts. Also record operational choices the supplier makes within an instructed service. Mark disputes and missing facts. These inputs allow counsel to assess the proposed role without reconstructing the product from marketing material.

Subprocessor chains need the same precision. EDPB Opinion 22/2024 addresses controller obligations when processors and subprocessors are used. A company name alone is not enough for the response map. Identify the contracting entity, service feature, processing activity, data categories, locations where relevant, authorization route, notice condition and the evidence available for the exact chain.

**Role analysis inputs for one activity**

| Question | Fact to preserve | Decision owner |
| --- | --- | --- |
| Why does the activity occur? | Purpose and permitted instructions | Privacy or legal reviewer |
| Who defines essential means? | Data, people, recipients, duration and material processing choices | Privacy or legal reviewer |
| What does the supplier choose operationally? | Implementation decisions inside documented instructions | Product and service owner |
| Who else processes the data? | Entity, activity, feature, data, location and authorization | Privacy owner and supplier manager |
| What remains unresolved? | Missing fact, legal issue and answer consequence | Named authorized reviewer |

## Map each buyer proposition to an operational safeguard

Split a broad privacy question into conditions that can fail independently. Purpose limitation, minimization, transparency, accuracy, retention, access, deletion, portability, objection, processing instructions, subprocessor governance, incident assistance, audit support and impact-assessment assistance are not interchangeable. Security controls can contribute to confidentiality or integrity, but they cannot establish purpose, necessity or a lawful role.

Give each proposition a relationship state. Direct support means the safeguard and evidence address the full statement. Partial support names the missing data category, copy, event or period. A customer dependency identifies an action the buyer must configure or perform. A contractual dependency needs an agreed term. Legal review required identifies a conclusion that facts cannot settle. Unsupported is the correct result when no current mechanism or usable evidence exists.

NIST Privacy Framework 1.1 can provide shared outcome language and supports profiles, mappings and communication across a processing ecosystem. It does not decide an organization's legal duties. ISO/IEC 27701:2025 can support a privacy information management system. Neither reference proves that the retention job ran for this tenant or that the proposed role is legally correct. Follow the reference down to the exact implementation and record.

**Relationship states in the privacy map**

| State | Meaning | Response treatment |
| --- | --- | --- |
| Direct support | Current safeguard and evidence cover the complete proposition | May support approved wording |
| Partial support | A named category, copy, path, condition or period remains open | Narrow the claim and route the gap |
| Buyer dependency | The outcome requires a customer instruction or configuration | State the handoff accurately |
| Contractual dependency | The proposition depends on an agreed term or authorization | Do not call the draft term current |
| Legal review required | Operational facts exist but the role or legal conclusion is open | Hold that conclusion |
| Unsupported | No current safeguard or evidence was found | Block the positive assertion |

## Test records, settings and execution without merging them

A processing record describes the activity. A policy states governance. A contract allocates responsibilities and instructions. Product documentation describes supported behavior. Configuration evidence shows the buyer-specific setting. Operating records show that a request, deletion, notification or review occurred. An impact assessment records a structured risk evaluation and its decision. Keep each object attached to the proposition it can prove.

Exercise important workflows. Submit an access or correction request using a representative test record and trace its identity check, search, export, review and response handoff. Trigger the configured retention rule and reconcile the target population with removed, excluded and failed objects. Test how restored backups, legal holds and customer exports are treated. The aim is not to expose personal information but to verify the control path with safe test data and controlled logs.

A DPIA does not become a general certificate. EU and Swiss guidance treats impact assessment as a record of a defined processing operation, its risks and proposed measures where the relevant threshold applies. Record the activity, version, assessment date, consulted parties, open measures, approval and review trigger. Let the authorized reviewer decide whether an assessment is required and whether residual risk is acceptable.

**What privacy evidence can and cannot establish**

| Evidence | Useful claim | Limit |
| --- | --- | --- |
| Processing record | Purpose, parties, data, recipients, retention and safeguards recorded | May not match current product behavior |
| Policy or standard | Approved governance and required practice | Does not prove tenant configuration or execution |
| Agreement | Accepted instructions, duties, assistance and authorization route | Does not prove the operational step occurred |
| Configuration and test | Feature behavior in a named edition and setup | Does not prove the whole operating period |
| Operating record | Action completed for a defined population and date | Does not settle the legal role or basis |
| Impact assessment | Risk analysis, measures, decisions and open actions for its scope | Does not certify every processing activity |

## Map a council recruitment platform question activity by activity

A fictional local council is buying a hosted recruitment platform for temporary care workers. Its RFP asks whether the supplier acts only on documented instructions, collects only fields selected by the council, helps answer access and deletion requests, uses authorized subprocessors, and erases unsuccessful applications after 180 days. The offer includes candidate intake, interview scheduling, email and text reminders, support and product telemetry.

The map separates six activities. Application handling uses fields and workflows configured by the council. Scheduling uses applicant contact details and panel availability. Text reminders send a phone number and message payload to a named communications provider. Support may receive a controlled copy of a case. Security events have their own access and retention. Product telemetry records feature events under a supplier-defined improvement purpose that is not covered by the same instruction statement.

The configured retention job removes unsuccessful application records after 180 days and a population reconciliation shows the latest run. Email notification metadata follows a shorter schedule. Encrypted backups expire through a separate rotation rather than immediate item deletion. Candidate exports downloaded by the council leave the supplier boundary. The rights workflow finds active applications and support copies, but the current test did not include restored backup data. Each fact receives its own relationship instead of one blanket yes.

The proposed processor wording is supported for application handling, scheduling and council-directed messaging, subject to privacy approval. The telemetry activity is sent for a separate role and purpose review. The deletion proposition is qualified with the documented backup cycle and buyer-export boundary. The map does not decide the council's lawful basis or whether the proposed contract language is sufficient.

**Condensed recruitment privacy map**

| Buyer proposition | Activity and evidence | Result |
| --- | --- | --- |
| Process only on documented instructions | Application and scheduling activity maps, instruction clause and permission test | Direct support for named customer activities |
| Collect only buyer-selected fields | Field configuration, default-state test and optional-field inventory | Direct support for candidate intake |
| Use authorized subprocessors | Messaging activity, provider entity, notice route and current agreement | Contractual dependency pending buyer acceptance |
| Erase unsuccessful applications after 180 days | Retention configuration, latest population run and backup schedule | Partial until backup wording is approved |
| Assist with access and deletion requests | Workflow test across live records and support copies | Partial because restored-backup handling was not tested |
| Supplier acts only as processor | Separate activity facts for customer work and product telemetry | Legal review required for the telemetry purpose |

## Write the answer from approved facts and role language

Answer proposition by proposition. Name the service and configuration, describe the relevant activity, state what the safeguard does, identify material buyer or subprocessor dependencies, and point to the evidence the buyer may inspect. Use the terminology approved for the applicable jurisdiction. Do not replace an operational explanation with “GDPR compliant,” “privacy by design” or a certification title.

Keep present behavior separate from contractual and future commitments. “The current configuration removes the active application record after 180 days” is a product and operating statement. “The supplier will assist the controller” describes a contractual duty. “The parties are controller and processor” is a role conclusion requiring the authorized legal basis. Link them where necessary, but do not let one sentence silently prove the others.

Control disclosure. A buyer may need a subprocessor schedule, data-flow summary, retention description, test result or redacted impact-assessment extract. It rarely needs live applicant records, internal legal advice, full system diagrams or vulnerability details. Record the owner, approved audience and permitted form for every sensitive item before attaching it.

- Identify the activity, service edition and data population.
- State the approved role or mark it as pending review.
- Describe the safeguard in terms the buyer can test.
- Reference evidence with matching scope and date.
- Preserve buyer actions, subprocessor conditions and material limitations.
- Release only the wording and documents authorized for this procurement.

## Reopen the affected answer when the processing changes

Give the map a checked date and explicit change triggers. Reopen affected rows after a tender amendment, new buyer instruction, product release, optional feature, new purpose, new data field, inference, integration, recipient, subprocessor, country, support route, retention setting, rights workflow, incident process, assessment finding or revised legal position. Preserve the replaced state and the reason it changed.

Use factual states such as question captured, activity mapped, role review required, safeguard verified, buyer dependency open, contractual term pending, evidence incomplete, disclosure approval required, answer approved and superseded. These states keep work moving without pretending that a coordinator has resolved law, risk acceptance or contract wording.

Keep the privacy map with the procurement. A later questionnaire may reuse an activity record only after checking the buyer wording, service configuration, parties, purpose, data, locations, retention, legal context and evidence date. Reuse the verified facts and decisions. Do not carry forward the old yes or no.

## Useful outcomes

- Each buyer privacy statement remains linked to its source, definitions, response field, required date and offered-service boundary.
- Processing activities are separated by purpose, role, people, data, operation, recipient, retention and lifecycle.
- Controller, joint-controller and processor positions are recorded with factual rationale and an authorized review state.
- Buyer, supplier and subprocessor responsibilities are assigned to the exact activity and handoff they govern.
- Every proposition maps to a privacy safeguard, an explicit dependency or a visible unsupported result.
- Policies, processing records, contracts, configurations, operating records and assessments retain their distinct evidential roles.
- Rights, deletion, incident and audit assistance are tested through the real service path rather than promised generically.
- The released answer stays within approved legal wording and a controlled disclosure boundary.
- Material changes reopen the affected activity and every buyer claim that depends on it.

## Workflow

1. **Fix the question and offer.** Record the procurement, current question, definitions, bidder, service edition, configuration, integrations, regions, support model and proposed parties.
2. **Define processing activities.** Separate each purpose and record the people, data, source, operation, recipient, location, retention, deletion and decision point involved.
3. **State the role hypothesis.** Describe which party decides each purpose and essential means, which instructions apply, and which facts remain for privacy or legal review.
4. **Split the buyer proposition.** Turn compound claims about minimization, transparency, rights, processors, retention, security, incidents and audits into separate tests.
5. **Map safeguards and duties.** Connect each test to the product behavior, contractual term, operating procedure, owner, customer dependency and subprocessor obligation that supports it.
6. **Attach evidence by layer.** Link the approved record, configuration, test, event history, sample, assessment or agreement that proves the same activity and period.
7. **Obtain privacy approval.** Ask the authorized reviewer to confirm role wording, legal qualifications, disclosure and any proposition whose support is incomplete.
8. **Release and maintain.** Publish only approved claims, reconcile related answers and reopen the map after a relevant change to processing or authority.

## Key decisions

- Which document version, lot, response field and defined term control this privacy question?
- What exact service edition, feature set, tenant configuration, integration and support route will the buyer receive?
- Which natural people are affected, and which categories of their information enter the service?
- What purpose does each operation serve, and which party actually decides that purpose and its essential means?
- Does the supplier perform a separate activity for its own purpose that needs its own role and evidence analysis?
- Which data are collected, inferred, exposed, exported, logged, backed up, returned or erased at each lifecycle stage?
- Which supplier, buyer and subprocessor action is necessary for access, correction, export, objection or deletion?
- Does the configured retention behavior match every data category, copy, queue, log, export and backup in scope?
- What does each record prove, and what legal conclusion still requires authorized review?
- Which information may be disclosed in the bid, under confidentiality, or only through a controlled review?
- What change would invalidate the answer before award or service start?

## Risks

- A contract calls the supplier a processor while actual product behavior includes a separate supplier-determined purpose.
- One processing-record row blends customer content, account administration, support and telemetry despite different purposes and retention.
- A privacy policy is treated as proof that a deletion or rights workflow operates in the offered edition.
- The answer describes personal data by database name and misses attachments, free text, logs, exports and derived attributes.
- A subprocessor list names companies but not the activity, data, feature, entity or customer dependency that brings each one into scope.
- Encryption evidence is used to answer minimization, purpose limitation or retention questions it does not address.
- The buyer's deletion period is applied to the primary record while copies remain in search indexes, support tickets or exports.
- A tested rights request covers active records but not archived or restored data.
- A generic compliance statement hides an unresolved role, legal basis, transfer or high-risk-processing question.
- An internal impact assessment, data-flow map or subprocessor agreement is disclosed more broadly than its owner approved.
- An old privacy answer survives a new feature, purpose, data field, model, recipient or retention setting.

## Metrics

- buyer privacy propositions with a controlling source and fixed offered-service scope
- distinct processing purposes with their own activity record rather than a blended system entry
- activity rows with affected people, data categories, operations, recipients, retention and deletion behavior
- proposed party roles with factual rationale, named reviewer and decision state
- propositions connected to implemented safeguards and current evidence
- rights, deletion and incident-assistance claims tested through all relevant copies and handoffs
- subprocessors linked to the exact service feature, activity, data and approval condition
- privacy claims with approved wording, evidence references, disclosure class and review date
- material positive statements that depend on an unresolved legal conclusion or unsupported fact; target zero

## Frequently asked questions

### Is a record of processing activities enough to answer a privacy questionnaire?

No. It is an important description of processing, but the answer must confirm that the record matches the offered service and connect each buyer proposition to current implementation, operation and approved legal wording.

### Can the data-processing agreement determine whether the supplier is a processor?

The agreement is relevant, but the role assessment also depends on what each party actually decides and does for the specific activity. Record those facts and obtain authorized privacy or legal review.

### Does ISO/IEC 27701 certification prove the RFP privacy requirement?

It can support a claim about a privacy information management system within its stated scope. It does not by itself prove buyer-specific roles, purposes, configuration, retention, rights handling or processing legality.

### Should security and privacy controls use the same map?

They may link to some of the same mechanisms and evidence, but privacy also tests purpose, necessity, roles, transparency, rights and lifecycle. Keep the conclusions separate and connect only the shared facts.

### How should subprocessors appear in the answer?

Link each legal entity to the service feature, processing activity, data categories, authorization condition, agreement and relevant locations. A vendor name without its role and scope is not enough.

### Can a future configuration support a positive answer?

Not as current behavior. Record the planned setting, owner, approval, implementation date and acceptance evidence, then use only the future or contractual wording authorized for the bid.

### Must the full DPIA be attached to the proposal?

Not automatically. Confirm what the procurement requests and what the assessment owner permits. A controlled summary or redacted extract may be appropriate, but the disclosure decision requires review.

### When should the privacy mapping be checked again?

Recheck after a material change to the buyer question, service, purpose, people, data, operation, party, subprocessor, location, retention, safeguard, evidence or applicable legal position.


## Primary sources

- [Regulation (EU) 2016/679, General Data Protection Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng), EUR-Lex
- [Principles of personal data processing under the GDPR](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en), European Commission
- [Guidelines 07/2020 on the concepts of controller and processor in the GDPR](https://www.edpb.europa.eu/documents/guideline/guidelines-072020-on-the-concepts-of-controller-and-processor-in-the-gdpr_en), European Data Protection Board
- [Guidelines 4/2019 on data protection by design and by default](https://www.edpb.europa.eu/documents/guideline/guidelines-42019-on-article-25-data-protection-by-design-and-by-default_en), European Data Protection Board
- [Opinion 22/2024 on reliance on processors and subprocessors](https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-222024-on-certain-obligations-following-from-the_en), European Data Protection Board
- [Endorsed guidelines on data protection impact assessment, WP248 rev.01](https://www.edpb.europa.eu/endorsed-wp29-guidelines_en), European Data Protection Board
- [Using NIST Privacy Framework 1.1](https://www.nist.gov/privacy-framework/using-privacy-framework-11), US National Institute of Standards and Technology
- [OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data](https://legalinstruments.oecd.org/public/doc/114/body-text.en.html), Organisation for Economic Co-operation and Development
- [ISO/IEC 27701:2025, privacy information management systems](https://www.iso.org/standard/27701), International Organization for Standardization
- [Standard Data Protection Model version 3.1](https://www.datenschutzkonferenz-online.de/media/ah/SDM-Methode-V31.pdf), Conference of the Independent Data Protection Supervisory Authorities of Germany
- [How to document processing activities](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/how-do-we-document-our-processing-activities/), UK Information Commissioner's Office
- [Data protection by design and by default](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-by-design-and-by-default/), UK Information Commissioner's Office
- [Data protection impact assessments](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-impact-assessments/), UK Information Commissioner's Office
- [Processing activities register guidance](https://www.cnil.fr/fr/RGPD-le-registre-des-activites-de-traitement), French Data Protection Authority
- [GDPR guide for processors](https://www.cnil.fr/fr/reglement-europeen-sur-la-protection-des-donnees-un-guide-pour-accompagner-les-sous-traitants), French Data Protection Authority
- [Guidance on data protection impact assessments](https://www.cnil.fr/fr/ce-quil-faut-savoir-sur-lanalyse-dimpact-relative-la-protection-des-donnees-aipd), French Data Protection Authority
- [Outsourcing of data processing](https://www.edoeb.admin.ch/en/outsourcing-of-data-processing), Swiss Federal Data Protection and Information Commissioner
- [Guide to technical and organisational data protection measures](https://www.edoeb.admin.ch/dam/en/sd-web/eVhrh8wY3QcR/TOM_EN.pdf), Swiss Federal Data Protection and Information Commissioner


## Related articles

- [Answer an RFP privacy question before design is final](https://zephior.com/insights/answer-an-rfp-privacy-question)
- [How to answer data residency requirements without overclaiming](https://zephior.com/insights/answer-rfp-data-residency-requirements)
- [How to answer healthcare RFPs involving patient data](https://zephior.com/industries/answer-healthcare-rfps-involving-patient-data)
- [Which security control proves each RFP requirement?](https://zephior.com/insights/map-security-controls-to-rfp-requirements)