HIGH story-contact-detail-edit-screen-peer-mentor-004 8 pts
8
Story Points
High
Priority
Contact Detail & Edit Screen
Feature

User Story

As a Peer Mentor (Likeperson)
I want to access encrypted sensitive personal information (such as personal ID numbers and medical context notes) on a contact record, with explicit consent steps and full access logging
So that I can fulfill my coordination duties that require personal data while ensuring the organization meets GDPR compliance and can audit who accessed sensitive information and when

Audience Summaries

This story directly addresses the organization's legal obligations under GDPR by ensuring that sensitive personal data — including health information and national ID numbers used for Vipps-authenticated membership resolution — is never exposed without deliberate, auditable user action. Norwegian disability organizations face significant regulatory exposure if they cannot demonstrate controlled access to protected data categories. Implementing encrypted field display with comprehensive access logging creates an auditable trail that satisfies both internal governance requirements and external regulatory inspections. Failure to deliver this capability correctly risks substantial fines under GDPR Article 83, reputational damage among peer mentors who entrust their personal data to the platform, and potential loss of government funding tied to data protection compliance.

This is a trust and retention story: peer mentors who feel their sensitive data is protected are more likely to remain active contributors to the network.

This is a high-priority, high-complexity story with significant compliance stakes that requires close coordination between security, UX, and backend teams. Delivery involves at minimum five distinct components: the encrypted field display UI, the sensitive field warning dialog, the client-side decryption logic using session keys, the read receipt logging service, and the screen-reader live region announcer. Each component has its own acceptance criteria requiring dedicated test cases, including accessibility testing with real screen reader tooling. Dependencies on story-contact-detail-edit-screen-coordinator-1 must be resolved before integration testing can begin.

A legal or data protection officer review should be scheduled before UAT to validate that the logging schema captures sufficient detail for breach investigation use cases. Rollout risk is moderate: any regression in the masking logic could expose sensitive fields prematurely, so a staged release with feature flags and monitoring on the read receipt service is strongly recommended.

Implementation centers on five integrated subsystems. The encrypted field display component must render masked placeholder values and a lock icon by default, switching to decrypted inline display only after user acknowledgement — this temporary reveal must be scoped to the current screen session and reset on navigation away. Client-side decryption uses the user's session key via the field encryption utils module; ensure the key is never persisted beyond the session and that decryption errors are surfaced gracefully without leaking partial data. The sensitive field warning dialog requires a modal pattern with clear field identification and explicit consent framing.

The read receipt service must write access events (user ID, timestamp, field identifier, reason code) to a tamper-evident log — consider append-only storage or signed log entries. The live region announcer integration requires ARIA live region attributes on the field container; test with VoiceOver and TalkBack to confirm the announcement fires at the correct moment. Edge cases include concurrent field reveals, session expiry mid-reveal, and network failure during log write — the last of which should queue and retry to prevent silent audit gaps.

Acceptance Criteria

  • Given I am on the contact detail screen, When I view a field containing encrypted personal data, Then the field displays a masked placeholder value and a lock icon instead of the raw data
  • Given I tap an encrypted field, When the sensitive field warning dialog appears, Then it clearly states which field I am about to view and that access will be logged
  • Given I confirm access to an encrypted field, When the decryption completes, Then the actual value is displayed inline for the duration of my session on that screen only
  • Given I have confirmed access to a sensitive field, When the encrypted field display renders the value, Then the read receipt service records an access event with my user ID, timestamp, field identifier, and a reason code
  • Given a screen reader is active and I reveal an encrypted field, When the value is displayed, Then the live region announcer announces 'Sensitive field now visible — ensure privacy before proceeding'
  • Given I navigate away from the contact detail screen and return, When the screen reloads, Then previously revealed encrypted fields return to their masked placeholder state and require re-confirmation

Business Value

Norwegian disability organizations handle sensitive personal data under strict GDPR obligations, including health information and personal ID numbers required for Vipps-authenticated membership resolution. Without encrypted field display and comprehensive access logging, the organization cannot demonstrate GDPR compliance, cannot audit data access in the event of a breach investigation, and cannot protect peer mentors' personal information from unauthorized viewing. This story is a legal and trust requirement — failure to implement it correctly exposes the organization to regulatory fines and erosion of peer mentor confidence in the platform.