On the Monday the Horizonte association had to send its scholarship list, nobody could open the file containing the interview notes. The coordinator had changed jobs two months earlier. She had been the only administrator of the account where the team kept forms, permissions, and tracking sheets. She had not vanished through bad faith, and there had been no attack. The tool simply treated an individual account as the doorway to collective memory. It had been convenient for years. That Monday, an entire organisation discovered that its information was not merely on a platform; it was tied to one person, one email address, and decisions nobody had documented.
This kind of incident is often described as a password problem. It is deeper than that. It is digital dependency: a situation in which an essential activity can continue only while a company, account, permission, integration, or piece of knowledge that the group does not truly control remains available. Sometimes dependency appears when people want to change provider. At other times it arrives much earlier, when someone is ill, a phone breaks, a subscription expires, or a feature disappears. The question is not only whether we can download data. It is whether we can keep caring for it, interpreting it, and using it without asking permission from a single doorway.
Convenience can conceal a transfer of governance#
An integrated tool saves steps. It invites people to create a space, upload contacts, connect calendars, and automate notifications. Each improvement looks small and reasonable. The trouble begins when decisions about access, retention, and change are scattered across screens nobody reviews. Who can appoint another administrator, where billing is stored, what happens to an inactive account, which data appears in an export and which does not: these questions feel secondary until work depends on answering them quickly.
An integrated tool saves steps. It invites people to create a space, upload contacts, connect calendars, and automate notifications.
There is no need to assume malicious intent to recognise the risk. Many services are designed to make entry smooth and to let an organisation solve governance on its own. The result can be accidental dependency. A team adopts an app to reserve rooms; then adds member lists, care documents, and volunteer forms; eventually its activity calendar no longer works without the app. What began as a convenience becomes infrastructure, but nobody calls a meeting to decide which guarantees infrastructure should have.
That difference matters because data is not an isolated object. Beside a name can sit a history of permissions, corrections, confidentiality agreements, and explanations of how to interpret a note. If access is lost or control is handed to someone who should not have it, recovering a spreadsheet is not enough. People need to know which version was valid, who was allowed to see it, and which commitments accompanied that record. Dependency does not only make a future exit expensive; it can interrupt today's responsibility to the people whose data was kept.
The inventory that reveals single doors#
A useful first practice does not require buying another platform. It means drawing the doors in one concrete activity. Horizonte could begin with the scholarship process: receiving applications, interviews, documents, decision, notification, and archive. Beside each step it would record where it happens, who administers access, which account pays for the service, what data enters or leaves, and what would happen if that person or account became unavailable for a week.
The exercise usually finds more than one single door. Backups may arrive in an email inbox nobody checks any longer. The recovery number may sit on a treasurer's phone. The form may retain the original information while the selection criterion is written in a comment inside a different tool. An export may be technically possible but lose attachments, timestamps, or the link between an application and its consent. The point is not to make every member a specialist. It is to expose the dependencies already governing the work.
It helps to distinguish acceptable dependency from fragile dependency. Depending on an email service can be reasonable if there are alternative administrators, an understandable agreement, and a way to recover messages. Depending on a volunteer's personal account to manage sensitive information is fragile because an ordinary absence can halt the service. The test is not achieving absolute independence, which is impossible and unhelpful. The test is that a normal change does not leave someone without an answer or expose their data in order to regain control.
Share power without indiscriminately sharing data#
The response is not to make everyone an administrator. Granting broad permissions because people fear losing access can multiply privacy risks and errors. What is needed is a proportionate handover structure. For every critical system, two people with defined roles should be able to recover access, review who has permissions, and transfer responsibility when a change occurs. The second person does not need to read every document or use the tool every day. They need to know it exists, how to activate a protocol, and whom to ask for help.
Separating functions also helps. The person who can pay a subscription does not necessarily need to download every case file. Someone handling a correction request should be able to locate it without becoming a global administrator. And someone leaving an organisation needs a respectful exit: transfer work accounts, remove their recovery devices, and confirm what personal data they should no longer retain. A well-designed handover protects both the group and the person leaving. It prevents them from continuing to receive sensitive alerts or being called months later to open an urgent file.
A handover list can fit on one page. It includes the system name, its purpose, institutional administrator accounts, backup people, renewal date, support channel, and the procedure if nobody can sign in. What matters is reviewing it when the team changes, rather than storing it as a ceremonial document. Dangerous dependency rarely announces itself. It accumulates through small exceptions that appeared temporary.
Test continuity before it is needed#
Organisations rehearse fires, yet few rehearse the absence of their primary account. A continuity test can be done in one afternoon. Choose an important tool and ask a backup person to find the agreement, sign in with an appropriate permission, locate a particular record, export what is essential, and explain which data should not be moved without review. Then restore the normal state and note the obstacles. The purpose is not to demonstrate technical skill. It is to check that responsibility does not depend on private memory.
The test should include an uncomfortable situation: a notice that the plan expires tomorrow, a person asking to erase data, or an administrator who does not reply. These cases show whether anyone has authority to make a decision, whether the provider offers an alternative, and whether the team can honestly inform someone waiting for an answer. If the only solution is to share a personal password or grant emergency mass access, the system is asking people to solve one fragility with another.
Measuring the result changes the conversation. It is not enough to say an organisation “has a backup.” It can record how long a substitute took to reach a document, what information was left out of the export, how many permissions needed changing, and which people received unnecessary notifications. These observations reveal the real cost of dependency: coordination hours, additional exposure, and delayed decisions. They are evidence for negotiating an improvement, not a reproach to someone who did what they could with available tools.
Innovation keeps options open for people#
Genuine innovation is not measured only by a faster interface or a process with fewer clicks. It must ask who can intervene when the flow stops describing reality. If a platform automates a decision but prevents people from identifying who configured it, reviewing an exception, or moving context to another service, it has reduced visible work in exchange for concentrating invisible power. The initial saving may be real. So is the vulnerability being created.
This especially affects people who depend on an organisation for a scholarship, care, housing, or an administrative answer. If a team cannot recover an account, delay is not an abstract inconvenience for the person waiting. It can mean missing a date, repeating documents, or receiving no explanation. Data justice is not only about preventing leaks. It is about ensuring that information needed for a decision remains available, understandable, and correctable through reasonable routes.
Horizonte solved its Monday by locating a backup and creating two institutional accounts. But the lesson was not “open more accounts.” It was to agree that no essential activity would depend on one person without a handover, or on a tool without a basic explanation of exit and continuity. This week's concrete action is to choose one function that cannot stop—payments, service, files, or appointments—and ask what would happen if its administrator disappeared for five days. If the answer lives only in somebody's head, we do not yet have a tool. We have a dependency waiting for its moment to become visible.
