It’s an all too common situation. A company must protect the data privacy rights of its clients by restricting data access to personal information (PII) to only those who have a business need to see it. Different departments/groups are responsible for different clients so only they have a “need to know.” Yet, it’s discovers through an employee, a client audit, internal audit or regulatory review that the wrong employees have access to the wrong data. This must be then reported as a violation of either client contract, industry standard (PCI, HIPAA, SOX, etc.) or privacy regulations enacted by at least 30 US states* and most countries.   How did this happen?

I’m not talking about fancy database systems but the mundane files, emails and scanned documents that are part of day-to-day business. Companies use shared folders on a file server, Microsoft SharePoint or one of dozens of available document management systems to accomplish this task. Now all of these systems have sophisticated access control to tightly control who has access to what. Good people diligently laid out a folder scheme and access control plan to prevent unauthorized access. The problem is the lack of process for determining need-to-know and then subsequently reviewing.

As new people are on-boarded, lots of things must be done including granting access. New employees/contractors are often placed in user groups that best match their job description. These groups in turn have rights to many folders including client folders. The employee was not explicitly granted access to a client yet got access anyway. The problem is even worse when the employee leaves. You may feel your employee termination process is air tight, removing all systems access. It’s much trickier when employees change jobs within the company. You may not have a centralized way to know this even happened. And, there is not a good way to determine the resulting change in need-to-know. These process issues quickly lead to access control issues.

Companies that get on top of this problem realize that compliance must be approached from the business operations perspective. Business users do not (and should not need to) understand the concepts of access control lists and group inherited rights. Applying the KISS principle, the permissions must be kept simple in terms like: employee A has a need-to-know about client B   and: supervisor X manages the relationship with client B.

Have IT or whoever manages the security create a simple access control with just one rule: Only the client B team can access client B’s files and folders.

Then, during onboarding, have the new employee (or their manager) request membership to the client B team from Supervisor X, who then approves (or rejects).   Also have Supervisor X periodically review the client B team members to make sure they are still valid. Done. Now all you need to do is prove this process is really happening.

Automatic tracking allows an audit trail to be collected, proving:

• Each new employee received permission from the team supervisor to access the team files.
• The supervisor regularly reviewed and removed unauthorized members.
• Team add/remove requests can then be tied into any existing ticketing system to prove that the user was actually added or removed

But what if employees service multiple clients? What if supervisors manage multiple clients? All document management technology allows “Groups of Groups” to make it easier to add someone to multiple teams at once. However, this is a slippery slope where it’s very easy to give an employee access to an unintended group. It also makes the team review very difficult. Even though the supervisor will receive a few extra requests in their inbox, it’s well worth it to keep the access rules simple.

* Cal. Civ. Code 1798.82; Conn. Gen. Stat. 36a–701b; Fla. Stat. 501.171; Haw. Rev. Stat. 487N–2; Ind. Code 24–4.9–3–1; Illinois 815 ILCS 530/50 (Illinois H.B. 1260, effective date January 1, 2017); Iowa Code 715C.2; La. Rev. Stat. 51:3074 and La. Admin. Code tit. 16, pt. III, 701; Me. Rev. Stat. Ann. tit. 10, 1348; MD Code, Com. Law 14–3504; Missouri Rev. Stat. 407.1500; MCA 30–14–1704; Neb. Rev. Stat. 87–801 et seq. (L.B. 835, effective July 20, 2016); N.H. Rev. Stat. 359–C:20; N.J. Stat. Ann. 56:8–163; N.Y. Gen. Bus. Law 899–aa; N.C. Gen. Stat. 75–65; North Dakota; Or. Rev. Stat. 646A.604; R.I. Gen. Laws 11–49.3–4; S.C. Code 39–1–90; Vt. Stat. Ann. tit. 9, 2435; Va. Code Ann. 18.2–186.6; RCW 19.255.010 and 10 L.P.R.A. 4052. 2 Alaska Stat. 45.48.010 and 45.48.090, Haw. Rev. Stat. 487N–1 and 487N–2, Ind. Code 24–4.9–2, Iowa Code 715C.1, Mass. Gen. Laws ch. 93H, Neb. Rev. Stat. 87–801 et seq. (L.B. 835, effective July 20, 2016), N.C. Gen. Stat. 75–61, R.I. Stat. 11–49.3–3, RCW 19.255.010, and Wis. Stat. 134.98. 3 Ark. Code 4–110–104, Cal. Civ. Code 1798.81.5, Conn. Gen. Stat. 42–471, Fla. Stat. 501.171, 815 ILCS 530/45 et seq. (Illinois H.B. 1260, effective date January 1, 2017), MD Comm. Law Code 14–3503, MA 201 CMR 17.00 et seq., Nev. Rev. Stat. 603A.210, Or. Rev. Stat. 646A.622, R.I. Stat. 11–49.3–2, Tex. Bus. & Comm. Code 521.052, and Utah Code Ann. 13–44–201.