Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Monday, January 20, 2014

No More Chinese Walls

Great Wall 
Sometimes, users will tell me, "I'm happy for my contacts' records to be held on the database, but I don't want anyone else to see them. At all." Which rather makes my heart sink - as this almost completely defeats the object of having the records on the database in the first place. It’s a scenario known as a "Chinese Wall":  And I don't want to have to climb it.

To clarify, a Chinese Wall means that if, say, the Celebrity department are managing Richard Branson, and thus they obviously need to access his supporter record on the database, if the Community Fundraising team were to search for Richard Branson then they wouldn't even see that his record was on the database at all. Period. To them, he doesn't exist on the system full stop.

The problem with this is several-fold

These are just some of the issues with this:
  • First, if the Community Fundraising team do have a genuine reason to need to view/add data about Richard Branson, then if they don't know he already has a record on the database then they will add a new one - a duplicate record.
  • Secondly, both teams, including the Celebrity department, will be none the wiser that the other team has or is building a relationship with the charity. This can clearly lead to all sorts of problems, from multiple communications, multiple asks, embarrassment, DP issues and so on.
  • What if the Corporate team then look at the Virgin Group's record. Are they allowed to see that Richard Branson is the Founder of Virgin? One would presume so. But if they then try to click-through to his record, they'll find they can't. Is that a good thing? So will they keep information on Branson on some other part of the Virgin record?
  • What is Mr Branson phoned Supporter Care for some reason, and they couldn't see his record or his interaction & involvement with the charity? And yes, okay, I realise that specific scenario is unlikely but other VIPs etc might well do.
  • Or what if someone else in the charity is going to meet his spouse, who may not be managed by the Celebrity department? Are they allowed to see Richard Branson is married to her? Surely yes; but then… [return to above…]
I know some teams who "own" records like this say, Oh, well, all the other users have to do if they come across Branson is come and talk to us. But that of course presumes everyone else knows Branson already has a relationship with the charity, that they will do that, that they can be bothered to do that, that someone in the Celebrity team is available to talk… And okay, Richard Branson may be a well-known person in the charity, but what about the other celebrities/VIPs who are not? And if a Chinese Wall stretches to cover us more common folk then this doesn't even bear thinking about.

So what to do instead

When this request does happen, I try to dig further to see what the user really means, and usually it is one of the following points:
  • I don't want other users to contact my records; and/or:
  • I don’t want other users to see sensitive information about my contacts.
Both are potentially reasonable requests, but in both instances there are better ways to address the issue than just completely blocking access. I say "potentially" because the first point above, that you don't want someone else to contact your records, is something I bang on about a lot. Firstly, they are not "your" records - see my other blog on that - and secondly, if everyone in the charity does agree that you are the best relationship manager for such contacts then that still doesn’t mean that you should blanket stop other people from seeing such records.

Instead, for both instances, the first thing that can be done is that the record can be flagged as such, with whatever appropriate code/wording which will help everyone in the charity understand the relationship. And ensure processes are in place to manage that.

Secondly, protecting sensitive information such as Richard Branson's giving history or personal phone number, is clearly an important point, but what the database should do is still give limited access to such contacts' records so that other people can see they do exist on the database and understand the relationship, and simply block the sensitive information so that only those users who should be able to see it can see it. That's a far more effective and open approach.

This is my belief anyway.

The only walls I want to see on a fundraising database are Kim Wall, Roger Water's Wall, Max Wall, Wall's Ice Cream… [that's enough Walls - Ed].

But no Chinese Walls thank you.

Monday, November 26, 2012

The Challenge of Secure Communication Records in a Single, Shared database

Secret Bunker 
Most database systems can record contact/communication history with your contacts, prospects, donors, benefactors et al. i.e. letters/emails, meetings, phone calls, services used etc. But what if your organisation and security needs mean that only some of your users should only see some such communication records?

Let me give 2 examples:
  • If John Smith is a major donor, then you will want your major donor fundraisers to be able to see the communication record of the important meeting you had with John last week; but what if the detail in that meeting was so sensitive that you don't want fundraisers in other teams to be able to see it?
  • Or, what if you are using your database for benefactors as well as donors, and what if Jane Smith is both a donor and a benefactor - thus, if you add a communication about Jane which only your charity's "Services' users" should be able to see, maybe a Counselling Session she attended, then how do you stop the fundraisers from seeing the fact she attended that session?
Now, some database systems offer functionality around security so that they can completely hide such communications from specific users. However, if you completely hide all such communications, then what about the following case: a fundraiser opens Jane's record and because he can't see that Jane had 3 communications in the last month with your charity's service users, he thus has an incomplete picture of Jane's interaction with you and might therefore approach Jane with insufficient or inappropriate knowledge.

And if they can't see the total communication history, and you are basing any appeal letters, event invites on recent or total communications made, then such analysis may be skewed.

So, how do we show all database users that some sort of contact/communication was made with a donor/contact, but only show relevant users the details of such communication?

It isn't necessarily as easy as it might first sound. Many systems have "one line" (summary) overviews on a Communication History form showing all communications at a 'top level', and then you drill-down (double-click) into each instance to see the details of a particular communication made. So at the most basic level, you want to stop some users from being able to drill-down into the separate communications where they are of Type X etc. This might be possible in some databases.

But taking this a step further: if you, say, have the communication "subject" or communication "type" on that one-line overview, even those few words might tell the "wrong" users too much about that communication - especially in the example of where donors and benefactors are all held on the same database; in that instance, even a subject such as "Counselling Session" might be considered inappropriate for fundraisers to see.

So, ideally, you want one user to see a view where the subject/type is the full details, but another user should only see that "some form" of communication was made but not the details. That can be trickier than it sounds for database developers.

So I throw this question out to you all: if you use a database where this problem has arisen and has been resolved, then do let me know how in the comments below. Or if you are a database supplier who has got around this problem, tell us how in the comments below. Or if you have ideas/thoughts on any of this, or further examples of similar issues, again, add them below. I'd love to hear more.