Testing settings and reviewing access

1. Regulatory Concept & Core Standards

In this video we will consolidate a skill: review functions and access after platform changes. Use the case to test what you would do in a similar situation. We will explain the proposed response step by step so that you can understand each choice and recognise when more information would be needed. Examples use a generic platform and fictional data. Function names depend on the product. Suitability and compliance of a particular installation must be checked; the demonstration does not certify functions in a particular UNOVOX licence.

Settings may become unsuitable after staffing changes, new integrations or product updates. Reviews must cover who has access, which actions they can perform and how actions are logged. Plan recovery and continuity tests with the technical team. Real cases need not be exposed to verify permissions and processes.

Apply the following rule: Article 7 generally requires register data to be kept for five years after the procedure ends, unless another Act provides otherwise. Personal data and the report’s contents are then destroyed; register metadata and the article 12(5) report may be retained longer under internal rules. This does not permit indefinite retention of the entire case. Clearly unnecessary personal data must not be collected and, if collected accidentally, must be deleted without undue delay.

2. Practical Implementation & Procedure

List active accounts, compare them with current roles and remove unnecessary permissions. Test changes with fictional data and document results. Check that exports, notifications and support access remain restricted. Repeat affected tests after changes and retain the approved configuration. A review without an owner or evidence is difficult to monitor. Before moving on, turn this procedure into a sequence you could explain to a colleague. Identify the first check, the action that depends on its outcome and the record that allows the decision to be reconstructed. Follow the sequence on screen and identify the point where an error would change the result.

3. Case Study & Compliance Action

A former trusted person still has active access. Deleting the account would also remove attribution of past actions. The team disables login while preserving history under applicable record rules. Now read the case carefully. Separate established facts from information you would still need to confirm. Do not add motives or events that have not been described. This distinction matters when choosing a response proportionate to the information available.

The exercise is as follows: Must case history be deleted to revoke access? Choose an answer and write one sentence explaining it. During the pause, compare your choice with the criteria we have just considered. Also think about the material you would retain to explain the decision later.

No. Separate active authority from legitimately retained records. Document the change and check each category’s retention rule.

One mistake to avoid is: leaving old accounts active to avoid reviewing permissions.

Now apply the national rule to a second decision. The system deletes every item two years after receipt. Is this suitable?

No. Two years since the breach ceased concerns protection, not retention. Article 7 generally uses five years after the procedure ends unless another Act provides otherwise. Distinguish destruction of personal data and contents from possible longer retention of permitted metadata and the report.