The post has been translated automatically. Original language: Russian
The agency can simultaneously conduct three similar surveys: a customer experience survey, an event assessment, and an internal employee survey. While there are few projects, they are easy to distinguish by name. But one incorrectly granted access, a copied link, or a shared response file — and one client's data ends up in the contour of another.
The problem usually arises not in the questionnaire itself, but in the organization of work around it. Below is a practical diagram that helps to separate projects even before the first answers appear.
Where projects start to mix
Most often, confusion appears after the launch: an employee duplicates the survey along with the answers, invites a client to a shared account, uses the same domain for several customers, or leaves access to a former contractor after the project is completed.
It is safer to proceed from a simple rule: each client is a separate working circuit. It should independently manage participants, surveys, registration, publication addresses, and results. The folder with the client's name inside the shared account does not always provide such a separation.
1. Create a separate workspace for each client
The workspace should be created at the beginning of the project, and not after sensitive responses appear. Only the materials of a specific client should be inside one contour.:
- questionnaires and their versions;
- responses and summary analytics;
- project participants and their roles;
- design, domain, and publication settings;
- decisions about data storage and deletion.
If one company conducts several studies, they can be separated already within its space. The main boundary is between clients, not between individual questionnaires.
2. Give access based on the principle of minimum sufficiency
NIST defines the principle of least privilege as providing a user with only the permissions and resources needed for their task. OWASP complements this approach with a recommendation to regularly review the rights and verify their actual operation.
For a small agency project, three clear roles are usually enough.:
- The owner manages the participants, settings, and final decisions on the data.
- The editor collects the questionnaire, checks the logic and analyzes the results.
- The observer sees a consistent result, but does not change the structure and accesses.
Do not grant administrator rights "just in case". A shared agent administrator can manage multiple projects, but the client's representatives should only see their workspace. After changing the team or completing the contract, access needs to be reviewed.
3. Migrate the template, not the client data.
Reuse of the structure saves time: question types, block order, scales, and service texts can be saved as a clean template. However, the answers, department names, respondent lists, logos, and internal comments cannot be transferred to the next project.
Before copying, make sure that the template does not contain the hidden context of the previous customer. Even a seemingly neutral field like "Your branch" may include response options with the names of specific cities or divisions.
4. Separate not only the answers, but also the external outline.
The respondent perceives the survey as part of the client's communication. Therefore, each project needs its own publishing settings.:
- a separate public link or domain;
- the right colors and visual design;
- current name of the organization;
- clear notification of the purpose of data collection;
- your confirmation text after sending the response.
Before launching, open the link in a private window and follow the respondent's path in its entirety. This helps you notice someone else's logo, old project name, or incorrect text even before the mailing list.
5. Determine the composition of the data and the storage period before launch
The temptation to add questions "for the future" increases the risk and makes it more difficult to communicate the results. The ICO's Data Minimization guide recommends first fixing a goal and then collecting only the information that is really needed for it. This is a guideline from UK practice, not a legal opinion for Kazakhstan.
- Write down which decision the survey should support.
- For each field, explain why you need this particular answer.
- Determine who will see the original responses and who will see only the summary data.
- Agree on the shelf life of the results and work files.
- Decide in advance what will be deleted, depersonalized, or transferred to the client after the project is completed.
If there is no need to link the answer to a person in the questionnaire, do not collect the name, phone number, or service ID automatically. Anonymity and confidentiality are different modes, and they should be described accurately to the respondents.
6. Perform an isolation check before sending the link
- Create a test user with the client role.
- Log in under it and make sure that no other workspaces are displayed.
- Check access to the questionnaire, analytics, and settings separately.
- Open a public link without authorization.
- Send some test answers and make sure they get into the right project.
- Delete the test data before the actual launch.
Such a check takes less time than analyzing the error after mailing. OWASP recommends checking permissions on each request and testing the access configuration, rather than considering it to be correct by default.
7. Close the project as carefully as you start it.
A completed survey does not mean a completed process. Use a short checklist to transfer the project.:
- stop or archive the public form;
- record the total number of responses;
- to transfer the agreed results to the client;
- delete temporary participants and verify the owner of the space;
- unlink a domain if it is no longer in use;
- make an agreed decision on data storage or deletion;
- keep only a clean survey structure for future projects.
A practical example
Let's imagine an agency that conducts customer experience research for three companies. All projects have the same basic questionnaire, but different brands, teams, and respondents. The agency creates three workspaces, copies a clean template into each, appoints company representatives as observers, and checks public links separately.
After completing the study, temporary access is closed, the client receives the agreed result, and only an impersonal template remains in the agency's library. The general methodology is being reused, but the responses and customer settings do not overlap.
What does this process look like in Wobidobi?
In Wobidobi, the separation of client work is supported by separate workspaces, custom brand and domain settings, and participant access control. This structure helps to organize the technical boundaries of the project, but does not replace the agreement with the client on roles, data composition and retention periods.
A brief conclusion
Secure work with multiple clients does not start with an additional report, but with the architecture of the process. Separate spaces, minimal rights, clean templates, isolation verification, and formal closure of the project reduce the likelihood of accidental mixing of data and simplify the work of the team.
Sources
Агентство может одновременно вести три похожих опроса: исследование клиентского опыта, оценку мероприятия и внутренний опрос сотрудников. Пока проектов мало, их легко различать по названию. Но один неверно выданный доступ, скопированная ссылка или общий файл с ответами — и данные одного клиента оказываются в контуре другого.
Проблема обычно возникает не в самой анкете, а в организации работы вокруг неё. Ниже — практическая схема, которая помогает разделить проекты ещё до того, как появятся первые ответы.
Где проекты начинают смешиваться
Чаще всего путаница появляется после запуска: сотрудник дублирует опрос вместе с ответами, приглашает клиента в общий аккаунт, использует один домен для нескольких заказчиков или оставляет бывшему подрядчику доступ после завершения проекта.
Надёжнее исходить из простого правила: каждый клиент — отдельный рабочий контур. В нём должны независимо управляться участники, опросы, оформление, адреса публикации и результаты. Папка с названием клиента внутри общего аккаунта не всегда обеспечивает такое разделение.
1. Создайте отдельное рабочее пространство для каждого клиента
Рабочее пространство стоит создавать в начале проекта, а не после появления чувствительных ответов. Внутри одного контура должны находиться только материалы конкретного клиента:
- анкеты и их версии;
- ответы и сводная аналитика;
- участники проекта и их роли;
- оформление, домен и настройки публикации;
- решения о хранении и удалении данных.
Если одна компания проводит несколько исследований, их можно разделять уже внутри её пространства. Главная граница проходит между клиентами, а не между отдельными анкетами.
2. Давайте доступ по принципу минимальной достаточности
NIST определяет принцип наименьших привилегий как предоставление пользователю только тех разрешений и ресурсов, которые нужны для его задачи. OWASP дополняет этот подход рекомендацией регулярно пересматривать права и проверять их фактическую работу.
Для небольшого агентского проекта обычно достаточно трёх понятных ролей:
- Владелец управляет участниками, настройками и окончательными решениями по данным.
- Редактор собирает анкету, проверяет логику и анализирует результаты.
- Наблюдатель видит согласованный результат, но не меняет структуру и доступы.
Не выдавайте права администратора «на всякий случай». Общий агентский администратор может управлять несколькими проектами, но представители клиента должны видеть только своё рабочее пространство. После смены команды или завершения договора доступ нужно пересмотреть.
3. Переносите шаблон, а не клиентские данные
Повторное использование структуры экономит время: типы вопросов, порядок блоков, шкалы и служебные тексты можно сохранить как чистый шаблон. Но ответы, названия подразделений, списки респондентов, логотипы и внутренние комментарии переносить в следующий проект нельзя.
Перед копированием проверьте, что шаблон не содержит скрытого контекста предыдущего заказчика. Даже нейтральное на вид поле вроде «Ваш филиал» может включать варианты ответа с названиями конкретных городов или подразделений.
4. Разделяйте не только ответы, но и внешний контур
Респондент воспринимает опрос как часть коммуникации клиента. Поэтому каждому проекту нужны собственные настройки публикации:
- отдельная публичная ссылка или домен;
- правильные цвета и визуальное оформление;
- актуальное название организации;
- понятное уведомление о цели сбора данных;
- свой текст подтверждения после отправки ответа.
Перед запуском откройте ссылку в приватном окне и пройдите путь респондента целиком. Это помогает заметить чужой логотип, старое название проекта или неверный текст ещё до рассылки.
5. Определите состав данных и срок хранения до запуска
Соблазн добавить вопросы «на будущее» увеличивает риск и усложняет передачу результатов. Руководство ICO по минимизации данных рекомендует сначала зафиксировать цель, а затем собирать только информацию, которая для неё действительно нужна. Это ориентир из практики Великобритании, а не юридическое заключение для Казахстана.
- Запишите, какое решение должен поддержать опрос.
- Для каждого поля объясните, зачем нужен именно этот ответ.
- Определите, кто увидит исходные ответы, а кто — только сводные данные.
- Согласуйте срок хранения результатов и рабочих файлов.
- Заранее решите, что будет удалено, обезличено или передано клиенту после завершения проекта.
Если в анкете нет необходимости связывать ответ с человеком, не собирайте имя, телефон или служебный идентификатор автоматически. Анонимность и конфиденциальность — разные режимы, и их стоит описывать респондентам точно.
6. Проведите проверку изоляции перед отправкой ссылки
- Создайте тестового пользователя с ролью клиента.
- Войдите под ним и убедитесь, что другие рабочие пространства не отображаются.
- Проверьте доступ к анкете, аналитике и настройкам отдельно.
- Откройте публичную ссылку без авторизации.
- Отправьте несколько тестовых ответов и убедитесь, что они попали в правильный проект.
- Удалите тестовые данные до реального запуска.
Такая проверка занимает меньше времени, чем разбор ошибки после рассылки. OWASP рекомендует проверять разрешения на каждом запросе и тестировать конфигурацию доступа, а не считать её правильной по умолчанию.
7. Закрывайте проект так же внимательно, как запускаете
Завершённый опрос не означает завершённый процесс. Для передачи проекта используйте короткий чек-лист:
- остановить или архивировать публичную форму;
- зафиксировать итоговое число ответов;
- передать клиенту согласованные результаты;
- удалить временных участников и проверить владельца пространства;
- отвязать домен, если он больше не используется;
- выполнить согласованное решение о хранении или удалении данных;
- сохранить только чистую структуру опроса для будущих проектов.
Практический пример
Представим агентство, которое проводит исследование клиентского опыта для трёх компаний. У всех проектов одинаковая базовая анкета, но разные бренды, команды и респонденты. Агентство создаёт три рабочих пространства, копирует в каждое чистый шаблон, назначает представителей компаний наблюдателями и отдельно проверяет публичные ссылки.
После завершения исследования временные доступы закрываются, клиент получает согласованный результат, а в библиотеке агентства остаётся только обезличенный шаблон. Общая методика переиспользуется, но ответы и настройки клиентов не пересекаются.
Как этот процесс выглядит в Wobidobi
В Wobidobi разделение клиентской работы поддерживается отдельными рабочими пространствами, собственными настройками бренда и домена, а также управлением доступом участников. Такая структура помогает организовать технические границы проекта, но не заменяет договорённости с клиентом о ролях, составе данных и сроках хранения.
Краткий вывод
Безопасная работа с несколькими клиентами начинается не с дополнительного отчёта, а с архитектуры процесса. Отдельные пространства, минимальные права, чистые шаблоны, проверка изоляции и формальное закрытие проекта снижают вероятность случайного смешивания данных и упрощают работу команды.
Источники
Share
