An important consideration with information security incidents is identifying if personally identifable information (PII) is involved. If it is, then the privacy breach response team needs to be put into action to determine whether or not an actual privacy breach occurred.

Answering the question, “Has a privacy breach actually occurred?” is not as easy a task as it may seem.

The defnitions of privacy breach vary greatly from country to country. I love talking with practitioners about their information security incident and privacy breach response plans and practices. I’m always interested in hearing the challenges and unique situations they run into. I often fnd that companies run into situations that they had not considered when they created a plan, but then have to deal with them in real-life situations.

Here are three of these situations, often overlooked and not planned for, but experienced by organisations.

Electronic messages accidentally going to the wrong internal recipient
I’ve spoken with at least a couple of dozen information security practitioners who have come across situations where someone on the internal corporate network has accidentally sent email messages containing PII to another person within the organisation who was not authorised to see the PII.

In one case, an employee in the accounting department meant to send an email containing PII such as employees' Social Security Numbers and medical information to the corporate lawyer, but accidentally sent it to an IT employee with a similar name.  

She realised the error when the IT employee called and asked if she really meant to send the email to a different employee.

Embarrassed, she said yes, asked the recipient to delete the email immediately, and then, following the documented corporate breach response plans, she notifed the information security department.  

So, is this a privacy breach?
It is a great question and good situation to discuss and debate. Certainly this is a recommended discussion between the information security, privacy and legal offces.

For each organisation to determine the best answer that applies, consider:

• What breach response laws apply to your organisation?
• Do the laws specifcally address this issue? Do the defnitions of a breach cover this situation?
• Did the recipient actually open the message? Do you have logs that can verify this?
• Have you interviewed the person who received the message to see if he or she read it?
• Based on your discussion, and any other issues related to the individual’s work history, do you have any reason to believe the recipient would abuse the information?

Passwords built into applications
Building in back-door access capabilities and coding passwords into programs are security poor practices probably as old as programming itself, but even as the number of incidents resulting from insider attacks continue to rise, the question that is assuming prominence is: what really is a privacy breach?

Over the past year, I’ve spoken with information security and privacy offcers who are pondering over this question. And for good reason — not only to seek clarity on the 'insider threat' issue, but also to understand how backdoors and hard-coded passwords can be exploited.

In one case, a programmer was updating an application hard-coded password to get access to the accounts of real customers  to test the application before putting it into production. A bad idea? Very. However, I bet a lot of programmers are putting this type of “testing” code into programs.

The situation became worse when the CISO discovered that the hard-coded passwords were left in the code when it was placed into production.

Not just in one program, but this had been going on for a long time for multiple application programs.

So, basically, all the programmers with access to the code also had access to the customers’ live accounts and associated information. Is this a privacy breach? Certainly this situation calls for a discussion between the information security, privacy and legal offces and all the related impacts and consequences.

Again, for each organisation to determine the best answer that applies, consider the following questions:

• Are the passwords actual passwords for the customers? Or, were they passwords made to work, by the programmers, to access the customer accounts?
• To what resources do the hard-coded IDs and passwords have access? Customer PII?
• Are the people who coded these backdoors and passwords still working at your organisation?
• Do the programmers have access to the same resources as those to which the hard-coded IDs and passwords have access?
• How many programmers have access to the code?
• Are the programmers contracted and employees of another company?

Employees taking PII when leaving the organisation
Now here’s a situation I know all organisations have had to deal with at one time or another: theft of PII by an employee leaving the organisation. With the widespread use of USB thumb drives and the ease of sending huge amounts of data through email attachments, the situation only gets more alarming. What's more — a growing numbers of personnel are mobile workers, and use the company’s laptops in their home offces, fully loaded with tons of PII, or even are using their own personally owned computers to do business work.

So, if you discover an ex-employee has taken PII with him or her, or the individual didn’t return a computer or storage device containing PII, or hard print papers with PII, is this a privacy breach?

In the past year a CPO at another organisation had an employee who had been approved to work from home on her own computer.

She did payroll activities for the company, and over the course of a year or so had basically accumulated all the employee PII relating to compensation, including benefts that had Social Security numbers and insurance numbers, onto her computer.

She apparently went through some personal hardships within her family, and unexpectedly called in one day and said she had to quit immediately to take care of family problems.

When asked to allow someone to come to her home to remove the company information and software from her computer, including the employee PII, she refused, saying that she had already deleted all the data and software, and she was not going to let anyone look at her personal and home fles, and she was simply too distraught to even think about the company any more.

So, is this a breach? There are defnitely many issues involved with this situation, beyond a potential breach. And yes, this is yet another recommended discussion between the information security, privacy and legal offces. But let’s focus for now on the breach issues.

You should consider the following:

• What were all the PII items that the individual had in her possession?
• Are there any logs or audit trails providin an indication of the this individual may have (mis)used the employee fles?
• What contracts, if any, were in place with this individual to work from home?
• What policies and procedures existed formobile working?
• Is there any legal recourse to persuade the individual to provide access to the computer and home offce area?
• Have there been any indications that the individual was planning to use the employee fles, or did she need money, and so on?-

Let’s consider each of these perplexing privacy issues by using just one regulation, possibly the most far reaching of recent breach notice laws — the HITECH Act breach notice requirements that expanded the reach of HIPAA.

The HHS provides the following in their guidance for complying with the HITECH Act.

“For purposes of these provisions, ‘‘breach’’ is defned in the Act as ‘‘the unauthorized acquisition, access, use, or disclosure of protected health information which compromises the security or privacy of such information, except where an unauthorised person to whom such information is disclosed would not reasonably have been able to retain such information.’’

The Act includes exceptions to this defnition for cases in which:   

(1) The unauthorised acquisition, access, or use of PHI is unintentional and made by an employee or individual acting under authority of a covered entity or business associate if such acquisition, access, or use was made in good faith and within the course and scope of the employment or other professional relationship with the covered entity or business associate, and such information is not further acquired, accessed, used, or disclosed; or...    

2) where an inadvertent disclosure occurs by an individual who is authorised to access PHI at a facility operated by a covered entity or business associate to another similarly situated individual at the same facility, as long as the PHI is not further acquired, accessed, used, or disclosed without authorisation (section 13400, defnition of ‘‘breach’’).”

Even though all the organisations used as examples were not necessarily healthcare covered entities or business associates, the defnition will serve for the purpose of our discussion.

Accidental electronic messages
The person sending the PII in an email message was authorised to access the PII, and the person who received it notifed the sender soon after she received the message of the error. The message did not leave the corporate network, or business email system. The recipient, during interviews said she deleted the message right away and the company confrmed the message was deleted soon after it was sent. Interview results determined she was not likely to have copied the message and no evidence could be found to indicate she had.

Since the message was unintentionally sent to the wrong person, an employee at the same organisation, during the course of work, and the message was confrmed deleted from the erroneous recipient’s email account, the organisation determined that no breach actually occurred, and that no notifcation was necessary.

The company provided information security and privacy training to both the sender and recipient, and then documented the incident and the training.

Coded passwords
The programmers were defnitely doing something bad, but interviews and discussions determined they were doing it because they believed that was the best way to test the programs; there were no policies, procedures or training addressing this type of activity.

While the access was technically unauthorised for the individuals, the programs were authorised for the access. The organisation decided not to treat this as a breach.

They implemented policies, supporting procedures, and provided not only training but also ongoing awareness communications to the IT areas about the need for incorporating security into their job responsibilities and programming activities.

They documented the situation and fled the documentation with their lawyer, who approved of the actions taken.

Ex-employees keeping PII
The insider threat has been shown to be very real and very signifcant. While this was a trusted employee, the organisation was completely taken by surprise by her sudden departure.

Even though she was authorised to access the employee PII as an employee, she immediately became unauthorised as soon as she quit.

And since she refused to allow the company to remove the PII and other company data and information from her computer and home, in addition to refusing to cooperate with the organisation, this was considered as a privacy breach, and the privacy breach response plan was put into action.

The organisation immediately implemented new policies, procedures, training, ongoing awareness communications and contractual requirements for their mobile workers. They also discontinued allowing personnel to use their personally owned computers to do business work.

They notifed all their employees of the breach and provided them with two years of credit monitoring as per their documented privacy breach response plan.

They also provided some question-and-answer sessions for the employees to ask the information security and privacy leaders, along with the legal counsel: questions about how a breach could potentially impact them, and the changes being made to prevent a similar situation.

Would your organisation make the same decision? Do you have personnel that work outside of your company facilities? Do you have contracted workers who do mobile working or work from home? Do you allow mobile workers to use their own personal computers and storage devices? Do you have policies, procedures and training in place for this issue? Think about it.

Follow the laws and use common sense
Of course using the HITECH Act defnition of a breach is just one defnition out of many defnitions in many different laws. Your organisation must consider all laws that apply to your organisation when making decisions in these types of situations.

You must comply with your applicable laws; that is a given.  However, most of the laws do not clearly cover the many obscure and perplexing issues involving PII that all organisations must address on an ongoing basis.

Many, and perhaps most, organisations often err on the side of being overly cautious and will send notices for all such situations.

I call this type of cautionary decision to send breach notifcations for any type of situation, inside or out, involving PII to be “over-notifying.”

The potential problem with over-notifying individuals about these types of possible breaches that may not really be breaches at all when considering all things involved is that the folks receiving the notifcation may get irritated that you alarmed them only to fnd out that the situation really did not put them at any risk of fraud or crime at all.

Common sense thinking also needs to kick in along with your incident response plans when considering breaches involving PII.

Know what the defnition of a “breach” is within all the laws that apply to you, and then plan for, and document, what you will do for obscure but common situations, such as those described previously.

Meet with your legal counsel and ask the questions provided here, and you will be well on your way to making some good decisions for your organisations.

By planning now you will save a lot of valuable time later, and your decisions will not be fettered and fuzzy by the stress of the active situation when it occurs.

—Rebecca Herold, CIPP, CISSP, CISM, CISA, FLMI, is an information privacy, security and compliance consultant, author and instructor with her own company, Rebecca Herold & Associates, LLC. This article is printed with prior permission from Infosec Island.