Ensuring Compliance In Corporate Monitoring and User Data Collection

-

Privacy is something I take seriously. As our world becomes increasingly interconnected and the boundaries between work and personal life blur, organizations must understand what they can and cannot do when it comes to monitoring corporate assets and environments.

If you’ve ever said something like:

“It’s a corporate-owned device, so we can monitor whatever we want.”

You’re wrong — and dangerously so. Before you deploy any monitoring tool, you should be familiar with the privacy laws in your province and at the federal level. The reality is far more nuanced than many IT teams realize, and the consequences of getting it wrong can be severe.

This topic doesn’t get nearly enough attention, and that’s a problem for both users and administrators. So let’s talk about it.


Corporate-Owned Device ≠ Unlimited Access

A common misconception is that ownership of the device, the credentials, or the network gives an organization carte blanche to inspect anything it wants.

Let’s be clear: it doesn’t.

Any monitoring you perform should satisfy three criteria:

  • Need to Know – You require this information to maintain security, compliance, or functionality.
  • Need to Collect – You must gather this data to achieve a legitimate business or security purpose.
  • Need to Inspect – You must review this data to fulfill that purpose.

If you cannot justify why you need to know, collect, or inspect a specific type of data, then you shouldn’t be collecting it. Full stop.

And if you can’t explain to a user why you need their information, they shouldn’t be expected to hand it over.


Actually Read the Regulations

This should go without saying, but if you’re deploying monitoring tools, you need to understand the legal framework you operate in.

Every province has its own privacy legislation, and different industries have their own standards and compliance requirements. When you monitor corporate assets, users, or data, you may be subject to:

  • Provincial privacy laws
  • Federal privacy laws
  • Sector-specific regulations
  • Employment law considerations

Yet I regularly see organizations rolling out “next-gen” security agents, NGFWs, cloud monitoring tools, and analytics platforms without understanding that the telemetry they collect could expose them to legal action — especially if users were never informed.

Ignorance isn’t a defense. If you’re collecting data, you’re accountable for it.


“There Is No Expectation of Privacy” — Not So Fast

This phrase gets thrown around far too casually. You can interpret it two ways:

  1. Assume nothing is private.
  2. Or — more responsibly — assume that if you claim nothing is private, you must clearly define what that means.

If you collect data that a user wasn’t aware of, you’re inviting trouble. If you fail to warn them, you’re opening an entirely different can of worms.

It takes almost no effort to include a notice in:

  • onboarding documentation
  • login banners
  • device registration workflows
  • acceptable use policies

Better yet, link users to a clear, accessible document that outlines:

  • what you collect
  • why you collect it
  • how it’s used
  • who can access it

Transparency isn’t optional — it’s foundational.


Understand Your Tools

This is where many organizations fall short. Deploying a monitoring tool without understanding what it collects is reckless.

You should know:

  • What telemetry the tool gathers
  • Whether that telemetry includes personal information
  • How to restrict or minimize data collection
  • How access to that data is audited
  • How long the data is retained
  • How to prevent misuse or unauthorized access

There is no excuse for not knowing what your systems are collecting. If you’re responsible for deploying or administering these tools, you must understand them — not just technically, but legally and ethically.


Final Thoughts

I have zero patience for organizations that hide behind vague “security purposes” to justify invasive monitoring. If you can’t clearly articulate why you need a piece of data, then you shouldn’t be collecting it.

This article comes from a debate I had some time ago, and I figured it was worth putting these thoughts into writing. Transparency builds trust. Overreach destroys it.

Side note: I’m not a lawyer — just a SysAdmin who cares about doing things the right way. If you need legal advice, consult a professional or review the regulations that apply to your region and industry.

Comments

Post a Comment

Popular posts from this blog

Using Power Automate to Update Contact Information

-
 We've all been there- you have a large organization who has out-of-date contact information. What do you do? You could go around to each department and ask them nicely to update their information, or send out an org-wide email prompting people to do so. However, this is tedious and oftentimes a pointless task. By the time you update one department, you're running to fix another. What if you could put the power back in the department's hands to do so? This is a struggle I faced recently as I was trying to find was I could conjure up some updated contact information for each department. As I did my research, I found that I was not alone in this endeavour as it seems that many IT professionals would love to make this process a little bit less painful. With this in mind, I introduce to you my latest flow! This flow will allow you to encourage users to update their contact information, without the overhead that comes with manual effort. In addition to this, this flow utilizes t...
Read more

Using Custom Connectors and Microsoft Graph API's to Manage Licenses in Power Automate - Part One

-
Happy June folks! I come to you with another post, but this time I wanted to change it up and show you something else I have just finished working on. As a SysAdmin, one of the most common issues we run into is managing licenses. Working at a post-secondary institution makes this an even greater challenge, as you have both students, staff and faculty constantly coming as well as going. Managing to keep up with this constant change can introduce great administrative overhead which takes away time from important upkeep of other systems and initiatives. You may also notice this same issue in large corporations or in other government organizations. To help combat this, I wanted to create a flow that can do the following: Get the user and their licenses Determine their last sign-in and the date Conditional to determine if the user is past the "cutoff" date Remove the user from a group where the license is assigned The only problem with doing this is that Power Automate does not ha...
Read more

Using Custom Connectors and Microsoft Graph API's to Manage Licenses in Power Automate - Part Two

-
Hello again! Didn't I promise you that I'd be back to wrap this up? Well, here I am to give you the second tidbit of information that you need to get this started. If you haven't already, take a look at my previous post where I go into depth about creating a custom connector in Power Automate to retrieve the latest sign-in and also gather the user's licenses. Now that we have the custom connector ready, we can now get into the meat n' potatoes of this series. In this post, I will show you the flow that makes this possible and how you can use the custom connector you have created to tie it all together! Hope you enjoy. Understanding the Logic Before we can begin creating the flow, we should first understand how the flow will work. I designed this to flow to be triggered manually, but you may want to schedule it or use another trigger. The trigger will depend on your organization's policies, so please adjust accordingly. Once triggered, the flow will use the Entra...
Read more