ホーム/実践ガイド/プライバシー・ガバナンス

プライバシー・ガバナンス

Map data flows and responsibilities

How do you build an actionable data map? Follow one processing activity from collection through copies, exports, backups and deletion. The register describes purposes, data categories, applications, providers, access, retention, owners and control evidence. The aim is to explain a decision, handle a request and verify a change. Examples concern methodology; legal classification depends on context and should be checked against original sources.

PrivacyRiskGovernance
無人のブリーフィング室にある世界ネットワーク地図
AIで生成した編集用イラスト

実践チェックリスト

  1. 01

    Describe purposes

    For each use, document the purpose, affected people and necessary data. Identify collection without a clear purpose and unnecessary copies. Start with a concrete operation, such as answering a contact request. Identify what is essential for that response and what serves another purpose. Avoid letting a broad label hide several distinct purposes and data paths.

  2. 02

    Trace data flows

    Map transfers between applications, providers and countries. Include backups, manual exports, logs and AI tools used by teams. Trace one case end to end with tool owners. Include attachments, local spreadsheets and automated integrations. Distinguish hosting location, access location and contracting entities; these describe different things.

  3. 03

    Name accountable owners

    Clarify who decides purposes, operates systems and validates requests. Connect contracts and responsibilities to observed processing. For each change, assign someone to decide and someone to verify implementation. A contract establishes a framework; checks must also examine actual access and the subprocessors really used.

  4. 04

    Define retention and access

    Set documented retention periods and verify implementation. Limit access by role and test deletion with a case including copies and justified exceptions. A retention rule is more than a value in a policy. Test an expired record, identify remaining copies and document exceptions. Backup arrangements require an appropriate, verifiable procedure.

  5. 05

    Review risks

    Assess the consequences of disclosure, alteration or unavailability. Have responsible specialists review impact assessment requirements and international transfers. Describe affected people, usage context and potential consequences before classifying a risk. Have competent specialists validate legal questions. Retain the reasoning behind the chosen action and its limitations.

  6. 06

    Maintain evidence

    Retain approvals, changes and tests. Review access requests, incidents and supplier changes at defined intervals. Review the map when adopting a tool, adding an export or introducing AI use. Preserve the request, approval and post-change test. A useful register reflects actual operations rather than an initial theoretical state.

    Worked example: a team stores customer requests in a SaaS platform and working exports. To test retention, trace a representative record through relevant copies, logs and backups. Distinguish immediate deletion, delayed expiry and justified retention. Record exceptions and remaining access rather than claiming complete deletion because the record disappears from the interface.

参照資料:データ・用途・限界

資料確認日 .

この言語版の詳しい参照メモは英語で提供しています。

参照資料:データ・用途・限界
出典と目的確認済みのデータ・指標利用方法留意する限界
FIRST · Traffic Light Protocol

Indicate who may receive redistributed information.

TLP 2.0 uses RED, AMBER, GREEN and CLEAR; AMBER+STRICT restricts sharing to the recipient organisation. Labels must not be translated. Keep the marking with the information and check recipients before forwarding. Ask the source to clarify any ambiguity.

手法を詳しく読む →

TLP is neither a formal classification nor a reuse licence. It does not guarantee content accuracy.
NIST · AI Risk Management Framework

Organise management of AI-related risks.

The AI RMF Core is organised around Govern, Map, Measure and Manage. It is a voluntary risk-management framework. Define intended use, affected people and error consequences. Connect each risk to an evaluation, owner and stop or recovery mechanism.

手法を詳しく読む →

The framework certifies neither a model nor an application. Using it does not remove the need to examine applicable requirements.
NIST · Privacy Framework

Examine risks to people arising from data processing.

The Privacy Framework is a voluntary privacy risk-management tool. It is distinct from a universal legal compliance checklist. Describe actual processing: data, purposes, recipients, access and retention. Compare documents, settings and deletion or retrieval tests.

手法を詳しく読む →

Using the framework alone does not determine compliance with applicable law. Processing context and jurisdiction still need examination.

公開とAI検索での可視性

この言語版の詳しい参照メモは英語で提供しています。

Assign publication decisions to an owner

Public publication and private access require different evidence. Snippet and AI participation choices must be linked to the relevant service and property.

  • Record owner, scope, effective choice and inherited publication settings.
  • Protect private resources through authorisation; robots.txt publicly reveals listed paths.
  • Date acceptance evidence and review documentation again when the service changes.

Compare AI controls and report data →

References reviewed

security.txtと脆弱性開示

この言語版の詳しい参照メモは英語で提供しています。

Preserve contact scope when domains change

A migration, provider delegation or subdomain change can make a disclosure channel ambiguous. Domain governance should therefore include publication and review of security.txt.

  • Check each relevant host: a parent domain’s file does not automatically apply to its subdomains.
  • Compare Canonical URIs with actual retrieval and document provider redirects.
  • Review contacts, keys, policy and expiry when responsibility transfers; preserve older versions as history.

Read the security.txt reference and disclosure cases →

Sources checked on · IETF · RFC 9116 · §2.5, §3, §5