Compliance & GovernanceAugust 5, 2026

What your security team can and cannot see about your activity

guide11 min

This guide is for non-engineers who want a realistic picture of workplace monitoring without fear, myth, or hand-waving. You will learn what data security teams usually can see across devices, apps, networks, and cloud systems, what they usually cannot see, and how to make practical decisions about privacy and acceptable use.

security-monitoringaudit-logsendpoint-securitybyodidentity-and-accessdata-loss-prevention

TL;DR — Security teams can usually see activity that touches company-owned devices, company accounts, company networks, and company-managed apps. They usually cannot see the contents of your personal device or private accounts unless you use them through company systems, install company management software on them, or local law and policy allow deeper inspection. Reading time: ~7 min

What it is and where it sits

When people ask, "Can the security team see what I do?" the honest answer is: they can see some layers very clearly, some layers only partially, and some not at all.

This is not one single tool. It is a stack of logs and controls spread across the places where work happens:

Device management (software that manages laptops and phones)
Identity systems (sign-in services like SSO, meaning single sign-on)
Network controls (VPNs, firewalls, web filters, DNS logs)
App and cloud logs (Microsoft 365, Google Workspace, Slack, GitHub, AWS, etc.)
Endpoint security (software on the device that watches processes, files, and suspicious behavior)

In older setups, companies relied mostly on the office network perimeter: if traffic passed through the office firewall, they could inspect it. That model has largely been replaced by a mix of device-based visibility and cloud/app visibility, because people now work from home, on mobile devices, and in SaaS (software as a service) apps.

A typical flow looks like this:

You on laptop/phone
      |
      v
Company-managed device agent (optional but common)
      |
      +--> Identity provider logs sign-in
      |
      +--> Endpoint security logs app/process/file events
      |
      v
Network path: Wi-Fi / ISP / VPN / company proxy / firewall / DNS
      |
      v
Cloud app or website
      |
      +--> App audit logs record actions in the app
      |
      v
Security team dashboards / SIEM (central log system)

What this means in plain language:

If you use a company laptop, the company may see far more than just websites visited.
If you use a personal laptop but sign in to a company app, the company can usually see what you did inside that app.
If you browse on your personal device and personal account with no company software, they usually cannot see that directly.
If your traffic goes through a company VPN or web proxy, they can often see the sites you connect to, and sometimes more.

The key boundary: ownership and control

The simplest way to reason about this is:

Company-owned thing = more visibility
Company account = visibility inside that account
Company network path = visibility into traffic metadata (data about the connection)
Personal thing, personal account, personal network = much less visibility

How it actually works

Let’s walk one realistic example end to end.

Example: you open a company laptop at home and upload a file to your personal Dropbox in the browser

Step 1: You sign in to the laptop

If the laptop is company-managed, it likely reports basic device facts to device management and endpoint security tools:

device name
serial number
operating system version
logged-in user
IP address (internet address)
whether disk encryption and antivirus are enabled

The security team usually sees that the device is active and who is using it.

Step 2: You open the browser and go to dropbox.com

Several systems may record this:

DNS logs may show that the device looked up dropbox.com
Web proxy or firewall logs may show a connection to Dropbox
Browser history may or may not be visible centrally; usually not by default, but it can be visible on the device itself if the device is managed or investigated
Endpoint security may record that Chrome, Edge, or Firefox launched and connected outward

If the company uses TLS inspection (a method that decrypts and re-encrypts secure web traffic on managed devices), they may also see more detailed web requests. Without TLS inspection, they usually still see the domain you connected to, but not the full page contents.

Step 3: You log in to your personal Dropbox account

This is where people often misunderstand the boundary.

The company can often see that you connected to Dropbox.
The company may or may not see that you performed a login event, depending on the network controls and endpoint tooling.
The company usually does not automatically get access to your personal Dropbox account contents just because you used it on a company laptop.

However, on a company-managed device, they may still be able to investigate:

browser downloads/uploads
local files accessed before upload
clipboard activity in some environments
screenshots or session recordings in tightly controlled environments, though this is not universal and should be disclosed by policy

Step 4: You upload customer-list.xlsx

The security team may detect this in a few different ways:

Data loss prevention (DLP) tools may inspect the file or upload event and flag sensitive data like customer records or credit card numbers
Endpoint security may notice that a sensitive file was opened and then a browser uploaded data to a cloud storage site
Proxy logs may show a file upload to Dropbox, even if they cannot read the file contents

If DLP is configured, the upload may be blocked, logged, or allowed with an alert.

Step 5: An alert appears in the security dashboard

The analyst usually sees something like:

user: jane@company.com
device: LAPTOP-1234
destination: dropbox.com
action: upload
file name: maybe visible, maybe not
sensitivity match: maybe "customer data" or "PII" (personally identifiable information)
time, IP address, and location

That is enough for the security team to know something happened, even if they cannot see every byte of the file.

What they probably cannot see in that same scenario

If you then pick up your own personal phone, turn off Wi‑Fi, use mobile data, and open your personal Dropbox app there:

the company usually cannot see that activity
the company usually cannot see your phone contents
the company usually cannot see your personal app messages or files

That changes if you installed company management on the phone, enrolled it in BYOD (bring your own device) management, or accessed company data through a managed work profile.

When to use it (and when not to)

Here, "it" means the visibility and monitoring controls a security team uses. As a customer of a software agency, your real decision is usually: what level of monitoring is appropriate for your staff, contractors, and client data?

Scenario	Recommendation
Agency staff use company laptops to handle client source code and production access	Use device management, endpoint security, SSO logs, and cloud audit logs. This is the normal baseline.
Contractors use personal laptops but only access a few SaaS tools	Prefer browser-based or app-based access with SSO and audit logs; avoid trying to monitor the whole personal device.
Team handles regulated data such as health, finance, or government workloads	Add DLP, stronger logging, and managed devices. Be explicit in policy about what is monitored.
Small team with low-risk brochure websites and no sensitive data	You probably do not need deep endpoint monitoring on every personal device; start with SSO, MFA, and app audit logs.
You want to know "everything employees do"	Do not frame it this way. Collect only what supports security, compliance, and incident response. Over-collection creates legal and trust problems.
You need to investigate data theft or account compromise	Use logs from identity, endpoint, network, and cloud apps together. One source alone is rarely enough.

You probably don't need this if...

your team only uses a few cloud apps and no one stores sensitive client data locally
you can reduce risk more cheaply with MFA (multi-factor authentication), least-privilege access, and managed company accounts
your contractors work on personal devices and your contracts do not allow invasive monitoring
your main concern is productivity, not security; security tools are poor substitutes for management

Trade-offs

Every visibility gain costs something.

Benefit	What it costs
Detects compromised accounts and suspicious logins	More identity logs to review, more alerts, and possible false positives when people travel or use new devices
Detects malware and risky software on laptops	Endpoint agents can affect performance, create privacy concerns, and require ongoing tuning
Shows access to risky sites or data exfiltration attempts	Web proxies, VPNs, and TLS inspection add complexity and can break some apps
Helps prove what happened during an incident	Log storage costs money, and keeping logs longer raises privacy and governance obligations
Protects client data with DLP	DLP often blocks legitimate work until rules are tuned; users may find workarounds
Gives visibility into SaaS activity	Each app logs differently, and integrating them into one dashboard takes engineering effort
Reduces risk on personal devices through BYOD controls	BYOD can damage trust if users think the company can see all personal data; policy and technical boundaries must be clear

A practical rule: monitor the company account and the company data path first. Only monitor the whole device when the risk justifies it.

In practice

Below are two examples you can adapt today. They are not "spyware" examples; they are normal security controls that define what can be seen and logged.

Example 1: nginx access logs show what your server can see

If your software agency runs a client-facing app behind nginx, the server can log the request path, IP, browser type, and response status. This is visibility at the application edge, not inside the user's device.

log_format main '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log main;

server {
    listen 443 ssl;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
    }
}

Gotcha: this logs the URL path and metadata, which may accidentally include sensitive query strings if your app puts secrets in URLs. If that is possible, change the app first; do not rely on log redaction later.

Example 2: Microsoft 365 audit logging is where admins see user actions in company apps

In a Microsoft 365 environment, admins typically use the compliance or audit area in the admin portal to search for actions like file downloads, mailbox access, and sign-ins. In your provider's dashboard, look for a path similar to Compliance portal → Audit or Admin center → Reports / Audit.

If you use PowerShell for a scripted search, it looks like this:

Search-UnifiedAuditLog -StartDate 08/01/2026 -EndDate 08/05/2026 -UserIds jane@company.com -Operations FileDownloaded,FileUploaded,UserLoggedIn

Gotcha: audit data retention and available event types depend on your license and configuration. If you search and see nothing, the first thing to check is whether auditing is enabled and how long logs are retained.

Example 3: DNS logs show domains contacted, not necessarily page contents

If your network team runs a DNS resolver (the service that turns names like example.com into IP addresses), query logs can show which domains devices asked for.

sudo journalctl -u unbound --since "2026-08-05 09:00" | grep "dropbox.com"

Gotcha: DNS logs show domain lookups, not proof that a user successfully loaded a page or uploaded a file. Modern apps also make many background DNS requests, so context matters.

⚠️ If you enable deeper inspection such as TLS inspection, endpoint recording, or DLP blocking, test with a small pilot group first. These controls can break logins, file uploads, developer tools, and mobile apps, and a bad rollout can interrupt client work.

A good implementation pattern for a software agency is:

In your identity provider dashboard, require MFA and enable sign-in logs.
In each major SaaS app, turn on audit logging and set retention.
On company laptops, install endpoint security and device management.
Only add web filtering, DLP, or TLS inspection where client data risk justifies it.
Write the policy in plain language: "We monitor company accounts, company devices, and company networks for security. We do not claim access to your private accounts unless you use them through company-managed systems."

Have a project in mind?

Get an instant AI price estimate for it, or talk directly to our team.

Get an instant estimate Talk to us

One email a month on what we learn building with AI