Policy to Ban Software Self-Installation: No Conflicts

Why ban self-installation and what pains does it solve

When employees can install software themselves, it may seem convenient at first. Need a PDF editor, a browser plugin or a messenger for a client — installed in 5 minutes and work continues. Problems appear later when dozens of such “quick fixes” accumulate.

Without rules, the same set of pains usually shows up: multiple versions of the same software coexist, updates break compatibility, support workload grows, license gray areas appear, and security depends on what and where someone downloaded.

Employees don't install software to be obstructive. The reason is almost always simple: “it's urgent,” and there's no clear, fast process. If approvals take days, people find workarounds. Often it's even seen as “initiative” until an incident happens.

A policy banning self-installation is not a ban for the sake of banning, but a way to make work predictable. It typically solves four goals:

• reduces risks and the number of incidents;
• makes support real (IT knows what's installed);
• brings order to licenses and versions;
• keeps speed — through a catalog and a simple request process.

The ban shouldn't become a wall. A practical approach is a clear catalog of approved software, a fast way to request new software and transparent exception rules. Then “you can't” becomes “here's how to do it correctly.”

Defining the scope: who it applies to and what we ban

A policy only works with clear boundaries. A phrasing like “nothing is allowed” almost guarantees workarounds and conflicts. Start by defining three things: who the rule covers, which devices it applies to, and what actions count as violations.

To avoid “IT banned it and the business suffers,” agree roles in advance. A typical process involves:

• employees (initiate requests and use the software);
• managers (confirm the need);
• IT (check compatibility, install and support);
• security (assess risks and access);
• procurement or finance (licenses, contracts, payments).

Next, set the device scope. For office PCs and laptops the rule is usually uniform. For terminals, classrooms and workstations with critical tasks the rules are typically stricter: stability and consistent configuration matter there.

Now the key: what exactly is banned. Describe the ban through actions rather than who is forbidden. For example, it's prohibited to:

• install programs without approval and license accounting;
• run portable versions and silent installers to bypass control;
• disable protections, policies or updates to perform installations;
• install browser plugins and extensions that affect browser security.

These points cover typical risks: malicious installers, licensing violations, version conflicts, performance drops and unmanageable setups (when nobody knows what's on the machine).

Separately, state what the policy does not interfere with. Routine updates of Windows and corporate apps, installing signed drivers and updates delivered via IT channels are usually allowed. If the ban blocks basic updates, trust in it will quickly fade.

Approved software catalog: how to make it clear

The approved software catalog isn't for control alone but to give the employee a simple answer to “what can I install to solve this task without breaking rules?” If the catalog is hard to find or looks like a list of hundreds of names without explanations, people will return to self-installation.

Make the catalog task-oriented, not organized by IT's internal structure. Categories that work well include office software, communications (email, chat, video conferencing), professional tools (accounting, CAD, healthcare), and utilities (archivers, PDF tools, drivers). Keep only what's actually used: better to have 5–15 popular solutions per category than “everything ever installed.”

Program card: the minimum that saves time

A card should answer basic questions without extra messages. Five fields are usually enough:

• Purpose: what problem it solves and who it's for.
• Owner: who in the company is responsible for selection and usage rules.
• License: type, who pays and what's needed for legal use.
• Version: allowed version or range, update frequency.
• Compatibility: which OSs, devices and key systems it works with.

Statuses to avoid a gray area

Statuses should be short and consistent for everyone:

• Allowed.
• Allowed with conditions (e.g., only for certain roles or with MFA).
• Under review (there's a request and it's being checked).
• Prohibited (and briefly why: risk, license, or an available replacement).

To get new programs into the catalog without disputes, decide in advance who decides and the criteria. Often it's a small group: security assesses risks, IT operations checks support and updates, procurement or legal reviews the license, and a business owner assesses the actual benefit. Keep criteria simple: security, legality, compatibility, total cost of ownership and availability of alternatives.

Request process for installations: make it fast and transparent

A self-install ban lives on speed and predictability. If people have to “fight” for access for weeks, the policy becomes a constant source of workarounds.

Provide a single entry point for requests: a Service Desk form, a template email or a single channel that is actually monitored. When there are many entry points (chat, DMs, “ask Vasya”), users quickly find the shortest but uncontrolled path.

Agree on a minimal set of data to avoid endless clarifications:

• why the software is needed (task and expected result);
• deadline (today, this week, project start);
• department and manager (who confirms need);
• device or user (where to install);
• license and budget (purchase, corporate license, free software).

Then set clear deadlines. Not “when possible,” but SLAs by request types. For example: urgent (work stopped), standard (planned tasks) and assessment (when security, compatibility and license checks are needed). That helps the business understand why one request is handled quickly and another takes time.

Statuses should be human and consistent:

• Accepted
• Under review
• Needs clarification
• In progress
• Completed

For urgent requests, record a promised time right away: “ready by 16:00” or “response on risks by end of day.” This reduces anxiety more than any regulation.

Step by step: how to roll out the policy without stopping work

The main mistake is turning on the ban abruptly without preparation. Users lose familiar tools and IT is flooded with urgent tickets. It's better to move in short steps and provide a working path first.

A practical rollout looks like this:

1. Inventory: what is already installed and what is actually used. Usually messengers, PDF tools, archivers, printer drivers and a few department-specific utilities appear.

2. Draft policy of 1–2 pages: what's allowed, what's not, how to request, timelines, who approves and how exceptions are granted. Clarity is more important than completeness at the start.

3. Pilot in one department: choose a team with many typical requests and agree on a feedback channel. After a week you'll see what stalls: extra approvals, lack of standard packages, unclear wording.

4. Configure rights and standard packages by role: a basic set should be installable immediately, the rest via request. Then the rule is seen as order, not punishment.

5. Roll out company-wide and review regularly: add frequently approved requests to the catalog, retire obsolete items and revisit owners and conditions.

In a well-tuned scheme, an “urgent tool for a task” doesn't become drama: the employee first checks the catalog, and if the needed item isn't there — files a request with purpose and deadline. IT either offers a safe alternative or issues a time-limited exception.

Exceptions: how to allow rare cases and keep control

A total ban without exceptions almost always breaks work. An exception is not “allowed once and forgotten,” but a documented deviation with clear conditions and a deadline.

Common exceptions are temporary (a few days), project-based (for implementation), role-based (for specific roles) and exceptions for special zones like labs or classrooms where frequent testing is needed.

Who approves

To avoid “IT vs business” fights, split responsibilities in advance:

• process owner (usually IT) checks if there's an option in the catalog or a safe alternative;
• security assesses the risk: source, license, data access, network behavior;
• the department manager confirms business necessity and agrees to the conditions;
• for high criticality the system or data owner is involved.

The exception request should record: purpose, program and version, source, device, what data is affected and what happens if the software isn't installed.

Duration and compensating controls

An exception must have an expiration and a review date, e.g., “30 days, review by the 15th.” This eases business fears that “it's banned forever” and keeps control.

If the risk is above normal, add simple measures that can actually be followed: install in an isolated environment (separate PC or profile), limit user rights, control updates, brief instructions and a clear uninstall condition (who and when removes the software).

Technical control in plain language: rights, roles, updates

The policy relies on simple technical rules. Otherwise workarounds appear: “temporarily give admin rights,” portable versions, disabling protection or chaotic updates.

The main principle is least privilege. Admin access is needed for those who maintain computers or specialized equipment. Most employees only need a regular account: it allows them to work but prevents installing anything.

Rights and responsibility

To avoid a queue of requests, fix roles:

• the employee files the request and describes the task;
• the manager confirms the software is needed for work;
• IT installs and ensures compatibility and support;
• IT and/or security record the result and periodically review exceptions.

This makes it clear who approved and who installed, and disputed cases are easier to resolve.

Basic software sets by role

A strong approach is ready-made packages for typical roles. Then most requests disappear because the needed tools are already installed. Examples:

• accounting: office suite, bank client/e-signature, PDF tools, printing and scanning;
• call center: browser(s), headset/telephony software, remote access, corporate messenger;
• engineers: CAD/CAE, equipment drivers, remote diagnostics, archivers;
• teachers: presentation and video tools, interactive apps, testing software.

Agree who owns each package: IT supports it, the business confirms its composition.

Updates without DIY

If updates happen “however they can,” employees will update themselves. Better to have one clear channel: centralized updates on a schedule, a pilot group for testing and a simple rule for quickly applying critical patches. That keeps workstation versions manageable and exceptions rare and visible.

Typical mistakes that spark conflict

Conflicts usually come not from the ban itself but from the feeling of a dead end: “it's forbidden” but unclear how to make it allowed quickly and safely.

Common trust-breakers:

• applying the ban abruptly without a transition, alternatives or promised IT timelines;
• a catalog that exists only on paper: old versions, missing items, unclear descriptions;
• no owner for decisions, requests bouncing between IT, security and procurement with no date given;
• exceptions granted permanently and nobody remembers why months later;
• communication based on threats, causing people to hide needs and bypass rules.

A typical scenario: someone needs a plugin, opens the catalog — it's empty or outdated. They contact IT, get told “create a request,” make one and then silence. By the deadline it's easier to ask a colleague with admin rights or download a portable version. The policy becomes a game of hide-and-seek.

A minimal helpful service level: a clear response time, a short answer “yes/no/need clarification,” regular catalog updates and temporary exceptions with review.

Quick checklist: is the process ready to launch

Before announcing the ban, check the process in real work:

• the approved software catalog exists, is easy to find, each program has a short description, who can use it and alternatives;
• requests are submitted one way (one form or service), not “message Pete in chat”;
• there are owners and deadlines: who decides, who installs, who manages licenses, how long a standard request takes;
• exceptions are described in advance: when allowed, for how long, who approves and how reviews happen;
• there is visibility: a report of installed software and a clear removal process (how we notify, record consent, and move data).

A practical test: ask a non-IT employee to find the catalog and submit a test request in 3 minutes. If they get stuck at “where to click” or “who to write to,” the process isn't ready.

Real scenario: how to agree with a team that needs something urgently

Sales comes to IT: “We need a messenger to communicate with clients and two browser extensions, otherwise we lose leads. We already installed them because we couldn't wait.” IT replies: “No, that's a risk. Remove them.” An hour later the conflict is at management level.

You can move the conversation from “allowed/not allowed” to “how to do it quickly and safely.” In 30 minutes you can agree if you follow a plan:

• record the purpose: why the messenger and each extension are needed (1–2 sentences);
• check risks with simple points: access to client data, authentication method, browser history collection;
• pick one supported option or issue a temporary exception with conditions;
• add the solution to the catalog and create a “sales standard package”;
• agree when the package will be available to everyone and who confirms the need.

The team gets not a permission to self-install but a ready package with correct settings. IT stops repeating the same manual steps and risks from unknown extensions leave the gray zone.

Next steps: lock rules in and support users

The ban works when people have a clear path: what to do if the needed program isn't in the catalog and who helps if the deadline is tight. Then the rule is perceived as a service.

A short one-week plan works well:

• collect inventory: what's installed and what's actually used;
• draft a catalog of 20–30 most common programs;
• choose a pilot group and run requests through the new process;
• record roles: who approves, who installs, who owns licenses;
• describe exception rules: when possible, for how long, who owns the risk.

To keep the process alive, track a few metrics:

• average time from request to installation (separately for urgent requests);
• share of refusals and reasons;
• number of exceptions and how many are extended;
• repeat requests for the same software (a sign the catalog doesn't reflect reality).

If there aren't enough resources for standardizing workplaces, inventorying installed software and supporting users, this can be handled by an external team. For example, GSE.kz (gse.kz) as a system integrator works with infrastructure and 24/7 support, helping maintain consistent standards without queues and manual agreements.