Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Is application code walking out your door when developers jump ship?

People change jobs. It’s a fact of life. And it’s dangerous.

While departing employees routinely stuff their pockets with Sharpies and paper clips to stock their home offices, it’s those piles of ones and zeroes walking out the door with them that should have us all terrified.

Consider this one finding cited in a brand new January 2017 white paper from Osterman Research: Fully 87% of departing employees take data they created and 28% take data created by others.

What are they taking, you ask? Nearly 90 took presentations or strategy documents, 31% took customer lists, and 25% took intellectual property. That last category is where program code fits. (And we’re not even talking about hackers.)

Some of this is intentional, some isn’t. The white paper notes that departmental so-called citizen developers are likely to have content on their personal devices. Part- or full-time telecommuters who use their home computers for work often have content stored locally. And yes, of course there are those who abscond with content on purpose. Limiting access does no good as these are the people who are supposed to have access.

But, some is intentional. The white paper discusses one software developer who learned she was to be terminated and began downloading “trade secrets,” which I interpret as code. The company initiated emergency legal action to prevent competitors from accessing the data. It happened at Goldman Sachs and even at security vendor Symantec.

Bob Spurzem, the go-to-market guru at Archive360 notes that it is common for developers that leave a company to take code with them. Beyond merely protecting a business’s data and other intellectual property when employees leave, “software developers require special attention,” he says.

“While we would like to believe this would never happen, a disgruntled developer leaving a business organization could steal code that equates to months, even years of work — putting a company’s competitive edge at serious risk,” Spurzem says.  “These threats are very real.  Dismissing them to the back burner is a dangerous mistake.  Businesses must plan for and take the appropriate steps to mitigate the risk.”

As I see it, it’s not just access to code. It’s also about access to design specs, test scripts, and subscription-based public cloud platform-as-a-service development environments. It’s about spinning up servers and database instances. Who’s in charge of disabling the departed one’s accounts? Or is he or she still using these development tools? Who is administering the administrators?

Have you known colleagues to take application code? (Of course, you would never do this.) What did your company do about it? And what measures does your organization have in place to prevent theft of code? Share your thoughts, we’d like to hear from you.