Ethics, Privacy and Professional Conduct

Access comes with responsibility

A junior service desk employee at a typical company can reset passwords, see who is in which group, and remote into laptops. A system administrator can read mailboxes, file shares and databases. A DBA (database administrator) can see every customer's address and payment history. Hardly any other job gives people that much access to other people's information on their first day.

Professional ethics are the principles that guide how members of a profession use the knowledge, access and trust that come with the work: what you do when nobody checks, and when the technically possible and the right thing differ. Organizations rely on audit logs and controls, but they mostly rely on you. Most ethical questions in IT are not dramatic; they are small moments:

• A famous customer's name appears in the ticket queue.
• A manager asks you to "just quickly" check what an employee has been emailing.
• A user's screen shows a medical letter while you are remoted in.
• A useful tool is free for personal use, and you want it on your work laptop.

The rest of this page gives you a way to handle each of them.

Confidentiality and need to know

Need to know is the rule that you access information only when a specific task requires it, even if your permissions would allow more. It complements least privilege: least privilege limits what an account can reach; need to know governs what a person does with the access they have.

In daily IT work that means:

• Do not look up colleagues, celebrities, neighbors or exes in customer or HR systems. Data protection regulators treat an employee viewing a medical file without authorization as a data breach (the Dutch Autoriteit Persoonsgegevens names it as an example); in the UK it can also be a criminal offense.
• When you remote into a user's computer, ask before you take over, say what you will open, and close or minimize documents and mail that are not part of the problem. Look away from what you do not need to see.
• Do not discuss what you saw. Funny ticket stories are fine without names or details that identify anyone; a user's private files, salary or health are never small talk.
• Collect printouts with personal data right away, lock your screen when you leave your desk, and do not leave customer documents on a shared printer or workbench.

Sometimes the request itself is the problem. Reading another employee's mailbox can be legitimate, for example during a formal investigation or to keep business running when someone is absent for a long time, but it must follow a documented procedure with approval from the right people (often HR, legal or the privacy officer), and it must be limited to what that purpose needs. A manager's verbal request is not enough, however senior the manager.

Sure, I've given you full access to Pieter's mailbox. Let me know
if you need his OneDrive as well.

Hi Femke, I understand you need the supplier contract from Pieter's
mail while he is on leave. Access to someone else's mailbox goes
through the access-to-employee-data procedure (KB-0233): it needs
approval from HR and the privacy officer. I've opened REQ-5130 for
you. Once it is approved I can search for that contract specifically,
rather than open the whole mailbox. Is there a colleague of Pieter's
who might have a copy in the meantime?

Using privileges only for the job

Admin rights exist so you can do your tasks. Using them for anything else, even something harmless, breaks the trust they are given on. Some concrete habits:

• Use a separate admin account for admin work and a normal account for mail and browsing, if your organization provides one (see separate admin accounts).
• Do not grant yourself access you were not given. If you need more rights for a task, request them through the normal process, even if you could add them yourself.
• Do not switch off logging, monitoring or security tools to make a task easier, and do not help someone get around a control "because it's faster". If a control is in the way, raise it.
• Assume your admin actions are logged and may be reviewed. Work so that a review would show nothing you would not want to explain.
• Stay within your competence. If a task is beyond what you can do safely, say so and escalate; see Working Safely on Production Systems.

Handling personal data

Almost everything in IT touches personal data: names in tickets, IP addresses in logs, email addresses in mail queues, photos on laptops. The GDPR (General Data Protection Regulation; in Dutch the AVG, Algemene verordening gegevensbescherming) sets the rules; the Security topic explains them. For your daily work they come down to a few habits:

• Use data only for the purpose it was collected for. Customer data in the billing system is for billing, not for your test environment.
• Take no more than you need. Export one record to reproduce a bug, not the whole table. Use test data or masked data outside production.
• Keep it where it belongs. No customer lists on USB sticks, in personal cloud storage, in private chat apps or in AI tools your employer has not approved (see what never to paste).
• Redact before you share. When you send logs or screenshots to a supplier, remove what the supplier does not need.
• Respect retention. Data has a retention period; when it ends, data should be deleted, including copies in exports, mailboxes and old test systems.

Some data needs extra care because of specific laws or contracts: payment card information, government-issued personal information (national identification numbers such as the Dutch BSN, the US Social Security number or the UK National Insurance number, and passport or ID card numbers), health data, and other personally identifiable information. Treat these as the most sensitive data you handle.

The redaction habit can be automated. Before Kestrel Energy's mail team attaches gateway logs to a supplier ticket, a small script replaces email and IP addresses, which can both identify a person. The supplier still sees the timestamps and errors it needs.

import re

# Lines from a mail gateway log, to be attached to a vendor support ticket.
log = """\
2026-09-30 08:14:02 reject from 198.51.100.23 to j.devries@example.com: spam score 9.1
2026-09-30 08:14:07 accept from 203.0.113.40 to m.chen@example.com: size 48213
2026-09-30 08:15:11 tls-error peer 192.0.2.77 cipher mismatch (client offered TLS1.0)
"""

EMAIL = re.compile(r"[\w.+-]+@[\w-]+(\.[\w-]+)+")
IPV4 = re.compile(r"\b(\d{1,3}\.){3}\d{1,3}\b")

def redact(text):
    text = EMAIL.sub("<email>", text)
    return IPV4.sub("<ip>", text)

print(redact(log), end="")

2026-09-30 08:14:02 reject from <ip> to <email>: spam score 9.1
2026-09-30 08:14:07 accept from <ip> to <email>: size 48213
2026-09-30 08:15:11 tls-error peer <ip> cipher mismatch (client offered TLS1.0)

A script like this is a safety net, not a guarantee: names in free text, customer numbers or IPv6 addresses would slip through. Read what you send before you send it.

Data breaches and other things you find

A data breach (datalek) is not only a hacker stealing a database. Regulators' own examples, such as those of the Dutch Autoriteit Persoonsgegevens (AP), include personal data sent to the wrong person, an employee viewing a file without authorization, a lost laptop or USB stick with unencrypted personal data, and ransomware that makes data unavailable. Many breaches are noticed first by someone in IT support: a user who says "I think I sent the customer list to the wrong address".

Your report may be exactly what makes the organization aware. So your part is simple and urgent: report at once through the official route, and leave the assessment to the people responsible for it.

INC-20802  P2  Possible data breach, reported to security 10:07
10:02  Lucía Romero (billing) reports she emailed an overdue-payments
       export (approx. 340 customers: names, addresses, amounts) to an
       external address at 09:48 by mistake: wrong autocomplete.
10:05  Asked her not to delete the sent mail and not to contact the
       recipient herself. Recall attempted: failed (external domain).
10:07  Reported to security and privacy officer via the security
       incident line, as per KB-0101. Assigned to the security team.
       No further action by the service desk.

Prohibited content and evidence

Occasionally a technician finds something on a device that may be illegal or seriously against policy: certain images, stolen data, signs of fraud. The professional response is the same as for a breach, with extra care for evidence:

• Stop. Do not keep browsing to "make sure", do not copy or move files, and do not confront the user.
• Preserve. Leave the device as it is (do not switch it off or wipe it unless instructed), and note what you saw, where and when.
• Report to your manager or the security team according to policy. The organization decides whether to involve law enforcement, and specialists handle the evidence with a documented chain of custody and in the right order of volatility.

NDAs and acceptable use policies

A non-disclosure agreement (NDA) is a contract in which one or both parties promise to keep certain information confidential and to use it only for an agreed purpose. In a mutual NDA (MNDA) both sides share and protect information, as is common before a supplier project. As an employee you are usually bound by a confidentiality clause in your employment contract; contractors, interns and suppliers often sign a separate NDA. Confidentiality does not stop when you change jobs: customer details, internal designs and security weaknesses of your old employer stay confidential.

An acceptable use policy (AUP) sets the rules for using the organization's IT: what you may install, whether private use is allowed, rules for email, internet and AI tools, and what the organization may monitor. Many systems show a splash screen or login banner that reminds users the system is for authorized use and may be monitored; it makes the rules visible and supports compliance requirements. As an IT worker you are held to the AUP like everyone else, and often more strictly, because your access is wider.

Software licenses

A software license is the legal permission to use software under stated conditions: how many users or devices, for what purpose, for how long, and what you may change or redistribute. Using software outside its license is a legal and financial risk for your employer, and audits by vendors do happen.

An end-user license agreement (EULA) is the license contract between a software vendor and the user, typically accepted when installing or first starting the software. Terms to watch for:

• Perpetual or subscription. A perpetual license lets you use a version indefinitely (updates may cost extra); a subscription stops working when payment stops.
• Personal or corporate use. Many tools are free for personal or non-commercial use only. Installing such a tool on a work laptop, or using it for client work, can breach the license.
• Per user, per device or per core. Counting matters when you clone a virtual machine or add users.
• DRM (digital rights management): technical measures that enforce license terms, such as activation keys. Circumventing them is not a fix for a licensing problem.

Open-source licenses

Open-source software is free to use, study and change, but it still has a license with conditions. They come in two broad families:

• A permissive license, such as MIT, BSD or Apache 2.0, lets you reuse the code, even in closed commercial products, as long as you keep the copyright and license notices (Apache 2.0 also gives an explicit patent license, which ends if you sue over patents in the work, and requires you to mark files you changed).
• A copyleft license, such as the GNU GPL, requires that modified or extended versions you distribute are released under the same license, with their source code. The AGPL extends this to software offered over a network; the LGPL is a "weak copyleft" that mainly applies to the library itself.

Many projects declare their license with an SPDX (Software Package Data Exchange) identifier at the top of each file, which makes automated checks possible:

# SPDX-License-Identifier: MIT
# SPDX-License-Identifier: GPL-2.0-only
# SPDX-License-Identifier: MIT OR Apache-2.0

Before you add a library to a company project or copy a snippet from a website, check its license. When in doubt, ask: many organizations have a list of approved licenses, and copyleft code in a product the company sells needs a legal decision, not a developer's guess.

Codes of ethics

A code of ethics is a written set of principles that a professional body expects its members to follow. In IT, membership and the code are usually voluntary, but some certifications make following a code a condition of keeping the certificate. Codes are not checklists; they help when a situation is unclear, and they give you words to explain why you decline something.

The ACM Code of Ethics

The ACM (Association for Computing Machinery) adopted its current Code of Ethics and Professional Conduct on 22 June 2018. Its general principles start with contributing to society and human well-being, avoiding harm, being honest and trustworthy, being fair, and respecting the work behind new ideas. Several principles apply directly to admin work:

• 1.6 Respect privacy.
• 1.7 Honor confidentiality.
• 2.6 Perform work only in areas of competence.
• 2.8 Access computing and communication resources only when authorized or when compelled by the public good.
• 2.9 Design and implement systems that are robustly and usably secure.

The ISC2 Code of Ethics

ISC2, the security certification body (written "(ISC)²" until 2023), makes "strict adherence" to its code a condition of certification. It has four canons:

1. Protect society, the common good, necessary public trust and confidence, and the infrastructure.
2. Act honorably, honestly, justly, responsibly, and legally.
3. Provide diligent and competent service to principals.
4. Advance and protect the profession.

Professional bodies

When something feels wrong

Sooner or later you will be asked to do something that feels wrong: hide an outage from a customer, back-date a change record, give someone access "just this once", or ignore a vulnerability because fixing it is inconvenient. A few steps help:

1. Pause and ask a question. "Can you help me understand why we do it this way?" Sometimes there is a good reason you did not know.
2. Name the concern plainly, in terms of the rule or risk: "That would bypass the change process" or "That gives access to personal data without approval".
3. Write it down. A short email confirming what was asked and what you said protects everyone involved.
4. Escalate if needed: to your own manager, the security or privacy officer, or a confidential counselor (vertrouwenspersoon) if your organization has one. Many organizations also have a formal procedure for reporting suspected wrongdoing.

Owning your own mistakes belongs here too. If you looked at something you should not have, sent data to the wrong place, or caused an incident, say so quickly. Early honesty limits the damage and builds the trust that the rest of this page depends on; see Blameless Postmortems and Learning from Mistakes. For the security habits that complement this page, see Security Awareness in Daily Work.