Skip to main content
All measures

Measure · ISO 27001

Restrict and check sensitive data flows

Establish which content and recipients a data flow needs. Implement access limits, suitable masking and leakage protection, then test permitted and prohibited cases.

Accountable: Information owners with application operations and privacy specialists where relevantReviewed

Reuse existing records

Reuse existing information classification, the access control concept and the existing approval, test or operational record. Add the decision, settings and result there. Do not create another classification list or a separate DLP policy per application.

What to do

  1. 1

    Establish purpose and permitted scope

    Choose an actual transfer, view or export from the existing information inventory. Determine the task, authorised recipients, required fields and approved route under the leading protection and access rules. Include indirect identifiers, business secrets and relevant original data.

  2. 2

    Implement restriction and masking

    Enforce the agreed access in the application. Reduce visible content, replace values or pseudonymise as appropriate for the purpose. Protect originals and necessary mapping information separately. Where needed, restrict copying, uploads, external sharing or portable media through suitable existing functions. Establish legal boundaries and necessary consultation before monitoring communications.

  3. 3

    Test permitted and prohibited paths

    Use suitable test data to check permitted use and a prohibited access or transfer. Include the actual export file, relevant interfaces and access to originals. Where anonymisation is claimed, check whether combinations with other available information can still identify people. Also check that a relevant alert reaches the right role.

  4. 4

    Maintain exceptions and changes in the existing record

    Keep purpose, decision, technical implementation and test results in the existing case. Handle false positives and approved exports under control. Use the existing incident route where disclosure is suspected. Revisit the rules when data, recipients or routes change materially. The leading testing and deletion rules apply to test copies.

Worked example

A support export does not need complete customer details

Records are to be sent to an approved support provider for fault analysis. Full names and account details are not needed for this task. This example is fictional.

Reduced export with restricted sharing
DecisionThe responsible role determines necessary fields and recipients. Operations removes or replaces unnecessary sensitive values, restricts the approved route and checks the actual export. A prohibited transfer attempt is prevented or detected and handled under the agreed rule.
EvidenceThe existing support or approval record links the decision, applied rule and suitable check result without an unnecessary additional copy of original data.

Record the result

  • Existing information or approval record with purpose, required data, recipients and protection decision.
  • Actual access, masking and transfer settings with suitable positive and negative tests.
  • Handled exceptions, relevant alerts and updated changes in the existing record.

Common implementation mistakes

Confuse a masked view with a protected export

Check files, interfaces and access to originals separately.

Call pseudonymisation anonymisation

Available mapping information or indirect attributes may still make people identifiable.

Treat encryption as permission to share

Even content that can legitimately be decrypted may have reached the wrong recipient.

Reuse the implementation across requirements

The references below show which requirements the measure contributes to.

View controls and standards
  • A.8.3 · Einschränkung des InformationszugangsGerman guide

    Permitted content and actions derive from the leading role model, are technically restricted and are checked through authorised and unauthorised access. The workflow does not replace the full access rights lifecycle.

  • A.8.11 · DatenmaskierungGerman guide

    Purpose-based reduction and masking consider access rules, protected originals and mappings, and checked identifiability. The actual method is implemented and legally assessed for the organisation’s data flow.

  • A.8.12 · Verhinderung von DatenlecksGerman guide

    The workflow considers sensitive data and actual leakage paths, configures suitable restriction and detection, and checks alerts, exceptions and response. Technical measures and legal boundaries must be applied to the specific situation.

Templates for your implementation

Related resources

Sources and further reading