CRM operations / Privacy by responsibility
Consulting relationships accumulate sensitive notes over long sales cycles. Evaluate a CRM around who needs that context, when they need it, and what should happen when their role changes.
01 / Establish the baseline
Before comparing products, trace a real prospect journey from first conversation to proposal and delivery. Note where personal information enters, who touches it, and where the trail becomes unclear.
List contact details, meeting notes, attachments, and correspondence. Identify fields that may contain sensitive information or details unrelated to the relationship.
Compare account partners, business development staff, consultants, and operations staff. Their responsibilities may overlap without requiring identical access.
Follow information through exports, account transfers, inactive opportunities, and departures. These are common points where ownership becomes ambiguous.
02 / The audit framework
Legal obligations depend on your jurisdictions, contracts, and the data involved. Work with the appropriate legal or privacy advisers to identify requirements, then test how each one would work in daily CRM operations.
Document the source, scope, and interpretation with the people responsible for privacy.
Name the role that approves, carries out, and reviews the relevant action.
Use a realistic account scenario to check the controls and record any gaps.
| Question | Responsibility | Evaluation prompt |
|---|---|---|
| Access | Account lead defines who needs context. | Can access be limited by role, account, or data type? How are exceptions approved? |
| Retention | Operations reviews records against the agreed schedule. | Can the team find inactive records and carry out its retention decisions? |
| Requests | Privacy owner coordinates the response. | Can relevant records be located, reviewed, corrected, or removed as needed? |
| Accountability | A designated reviewer checks changes and access. | What activity history is available, and is it detailed enough for the review process? |
03 / Selection tradeoffs
Fine-grained controls are only useful if the firm can administer them. Discuss these tensions with stakeholders before a product evaluation becomes a checklist of settings.
A proposal team may need the account stage and relationship owner, but not every meeting note. Ask whether different levels of detail can be separated without hiding the whole account.
Many custom roles can reflect real distinctions, but they also need maintenance. Test whether a small set of roles covers normal work and how exceptions are reviewed.
Past context can help an account team, while old details may no longer serve a purpose. Agree on review triggers and evaluate how records can be found when those triggers arrive.
04 / Put it into practice
Use a representative scenario rather than asking only whether a control exists. Include a partner, a proposal contributor, operations, and a privacy adviser in the discussion.
Return to the frameworkMark the moments when information is added, shared, exported, or handed over.
Specify who needs to view, edit, approve, and review each category of information.
Test a departing consultant, a temporary proposal team, and a request to find or remove information.
Separate product limitations from policy decisions and assign an owner to each gap.