Policy

An organisational policy is a set of rules and guidelines that tells everyone in an organisation how they are expected to work. It is written once for the whole organisation, not decided separately by each employee, so everyone follows the same agreed way of doing things.

One code of conduct in every location

A bakery with one shop in Leeds and another in Bristol still works to one set of rules. A policy makes sure staff in either place follow the same standards, so customers get the same service and nobody invents their own way of doing the job. Without one, each shop would drift into its own habits and quality would depend on who happened to be on shift that day.

Responsibilities and procedures

Policies set out staff responsibilities: who is answerable for what, how employees are expected to behave and what is not acceptable, so nobody can say they did not know. For example, a social media policy at a chain of indoor climbing centres might state that staff must never post photographs of customers online.

Policies also state the procedures to follow. A procedure is the step-by-step way to carry out a task or deal with a situation. The policy says what must happen and who is responsible; the procedure breaks that down into the actions a member of staff actually takes.

When something goes wrong

A policy also covers what to do if something goes wrong or a disaster occurs, such as a fire, a flood or a hacker wiping the main server. It states who takes charge and which procedure to follow, so people act instead of panicking.

Policies are not optional advice. Every member of staff works in line with them, whatever their role, including supervisors and senior managers. That gives consistency, clear expectations and a planned response when things go wrong.

An IT manager is the person who usually writes an organisation's IT policies: the rules that tell staff how to use systems safely and consistently. They are well placed to do this because they understand how the organisation's systems work and what can go wrong. They turn legal requirements into clear rules staff can follow, for example keeping personal data secure, and they do the same for business needs, such as letting staff work from home.

Reviewing policies

Writing a policy is not a one-off job. IT managers review policies regularly to check they are still suitable, and they recommend how policies should be updated. A review may be triggered by a security incident, a change in the law, new software or a new way of working. For example, at a chain of pet supply shops, the IT manager reviews the remote access policy after branch managers begin checking stock levels from home. The manager recommends adding a rule that company laptops must connect through the organisation's secure service before stock records can be opened. This closes a gap before it causes a problem.

Taking ownership

Ownership means the IT manager is accountable for making a policy change actually happen, not just suggesting it. They might plan the change, arrange training, explain to staff what is different and check that the new rules are being followed. They do not have to carry out every task themselves. IT and technical staff may update settings or reset accounts, while the IT manager sets the direction and makes sure the work is completed.

When an organisation defines responsibilities, responsibility for each policy is given to a designated employee rather than left to be shared vaguely by everyone. That person's name is attached to the policy, so anyone who needs guidance or a decision knows exactly who to approach.

One name behind each policy

The designated person does not have to carry out every task themselves. Their role is to be the point of accountability: the one who makes sure the policy is fit for purpose, kept up to date and genuinely followed. A single employee might be given a whole set of related policies to manage — for example, one member of staff could be named as responsible for every policy covering how customer information is stored and shared.

Most policies are carried out day to day by IT and technical staff. A technician might set up access rights so only the right people can open a folder, run the overnight backups, or check that colleagues are following the password rules. The designated person makes sure this is happening and steps in when it is not.

Why names matter

Naming someone makes them answerable. If a policy has gone out of date or is being ignored, there is a person who can be asked about it and who must put it right. It also stops responsibility being spread so thinly that nobody takes action. Some named roles carry a legal duty too: whoever is responsible for data protection must make sure the organisation keeps to the law on handling personal information.

If you have a concern about a policy, or about the way it is being carried out, you should contact the named person responsible for that policy. Your concern should be raised internally with a member of staff inside the organisation, rather than sent to the police, an outside regulator or management in general.

Who to contact

The named person is the employee given responsibility for that policy area. They know what the policy says, why it exists and what should happen when it is not followed, which makes them the right person to contact.

Why report internally

Raising the concern with the responsible employee means the issue can be looked into and dealt with by someone who has the authority to act. For example, at a bike repair company, a technician notices that customer repair forms containing phone numbers are left on a desk in an open area. The data protection policy says these forms should be locked away. The technician tells the named person responsible for the data protection policy. That person can investigate the issue, remind staff of the correct way to store forms or recommend a change to the policy.

Why defined responsibilities help

When responsibilities are defined, staff know the correct route and the person to approach. They do not have to guess or report to a general manager who may not know the policy. If responsibilities were not defined, staff would not know who to report concerns to, and policies would be applied inconsistently in different teams.

An acceptable software policy explains what an organisation does to help prevent the installation and use of unapproved software. Any program on a computer could contain a weakness an attacker can use, so the policy controls what software is allowed and how it gets onto the devices. It is not the same as an acceptable use policy, which covers how staff behave online rather than what software sits on the devices.

Why unapproved software is risky

• Malware can be hidden inside a program from an untrusted source and then spread across the network, so the whole organisation is affected, not just the one computer.
• Conflicts happen when a program does not work with the organisation's hardware, its operating system version or another program already installed, which can cause crashes and lost work.

How software gets approved

Users are usually forbidden from installing software or even updates themselves, because a helpful-looking tool can still be a risk. If someone needs something new, they either choose from an approved list or make a request. On the request they must justify why the job cannot be done without it — for example, a designer at a print firm explaining that a client sends artwork in a format the current program cannot open. An IT manager then considers the request, checking the licence cost and whether the program fits the existing setup before approving or refusing it.

What the policy protects against

Operating system safeguards support the policy: where a user account has no administrative rights, the operating system simply refuses to install new software.

A software audit is a check of the software installed on the computers an organisation owns. It compares what is actually on each machine with what the organisation believes should be there, and anything that does not match is put right.

Software audits and monitoring are how an acceptable software policy is enforced. The policy states the rules, but only an audit shows whether they are really being followed, because nobody can know by memory what is sitting on hundreds of machines. Monitoring software does the same job automatically by logging what each computer holds, so an audit does not have to rely on someone checking every machine by hand.

What an audit checks

An audit is not just a licence count. It checks four things:

Imagine a chain of six garden centres runs an audit. It finds the automatic ordering tool in the stock program switched on for all staff, though only the manager orders stock, so it is switched off for everyone else. It finds the stock program on 40 computers when only 28 tills run it, so 12 licences are dropped at renewal. It finds a laptop with a drawing package nobody bought a licence for, so that copy is removed. It finds two anti-virus products installed side by side, each paid for yearly, so the second subscription is cancelled.

Each finding saves money or keeps the organisation within the law, which is what the acceptable software policy is trying to achieve.

A usage audit uses a monitoring program installed across an organisation's computers to log which programs are installed and when each one is opened or used. The monitoring program quietly records, for every machine, the software found on it and the times that software is launched, then reports back. Over a few weeks this builds a picture of what is actually being used, rather than what people say they use.

What the log shows

Because the monitoring program timestamps every launch, the audit can flag programs that have not been opened recently: staff set a threshold, such as a term, and anything untouched within it appears in the report. A program that nobody has started on any computer for months is a strong signal that it is not needed. Each flagged program can then be investigated: perhaps one team still relies on it occasionally, or perhaps it was left behind when a project finished. If no one needs it, it can be uninstalled.

For example, a college's monitoring program might show that a video editing package was opened regularly until a media project ended, and has not been launched on any of the college's computers since. IT staff check with the media tutor, confirm the project is finished, and remove the software.

Why this supports the acceptable software policy

• Reducing vulnerabilities: every installed program is another piece of code that could contain a security flaw. Removing software nobody uses takes away those flaws before an attacker can exploit them.
• Avoiding licence costs: many programs are paid for per installation or per user. Uninstalling unused copies means the organisation stops paying to license idle software, and can renew fewer licences.
• Evidence, not guesswork: the log gives concrete proof of what is installed and used, so decisions to remove software are based on recorded facts and no one loses a tool they depend on.

In each case the audit makes the acceptable software policy easier to enforce, because it shows which software is present, who is using it and whether it earns its place.

A licence audit uses an auditing program to scan the computers owned by an organisation and compare what it finds. It looks for inconsistencies between different computers, such as one machine running an older version of a program than another, or a program appearing on a computer where it should not be. The audit produces a report that IT staff can act on.

What the report lists

For each computer, the auditing program records which programs are present, which version of each one is running, when it was installed and whether a licence is held.

This gives a full picture instead of just a count of copies. The report highlights where computers differ, so staff know which ones need attention.

Acting on the audit

The audit leads to remedial action: updating software to the latest version, purchasing a licence, or uninstalling software. For example, a theatre company's audit finds six box-office PCs still running version 2.3 of its ticketing program while the rest run 2.5, so those six are updated. It also finds a video editor on a backstage laptop with no licence record, so the company buys a licence or removes it.

An organisation normally buys permission to install and use a program on an agreed number of installations. Exceeding that number breaks the agreement, so the organisation must buy more licences or uninstall copies. A licence audit helps identify software installed without a licence, so the organisation can act and avoid legal action or fines.

An acceptable use policy (AUP) is a document that sets out how staff are expected to behave when they use an organisation's digital systems — its computers, network, email and internet connection. Everyone signs the same rules, so it is clear what counts as sensible use. It is not the same as an acceptable software policy, which deals with installing software.

Rules that protect access

Staff must keep their login details to themselves. Sharing a password, even with a trusted colleague, means the system can no longer tell who did what, so someone could see or change files they are not allowed to. Passwords must be changed regularly so an old leaked password stops working. A strong password — long, with a mix of letters, digits and symbols — is much harder to guess or crack than a short one.

Screens should lock automatically after a short period of inactivity, and staff should sign out at the end of a session. An unlocked login lets the next person read confidential information, such as client notes or bank details.

Rules that protect the network

A wallpaper file from a fan site can hide malicious code, so staff should not download files from the internet without IT approval. A memory stick from home can carry malware, so connect only organisation-issued removable media. Work equipment should not be used for streaming films, shopping online or personal email, because these tasks add more chances for malicious adverts or links to appear.

Rules that protect people

Opening a website with offensive jokes or rude images can make nearby colleagues uncomfortable, so sites like these are banned. Cyberbullying — for example, repeatedly excluding a colleague from a team chat or adding mocking emojis — is banned because it can make someone feel isolated and anxious. If equipment is damaged or stolen, report it to the service desk straight away so it can be repaired or replaced and, if stolen, its account disabled and files wiped remotely.

A disaster recovery policy should state who is responsible for each recovery action, so every task has a clear owner. This is more than saying “IT will deal with it”: the policy names the role that must carry out each action.

Responsibilities should be linked to job roles, such as systems administrator or network technician, rather than named individuals. The responsibility stays in the policy when someone leaves or changes job, and whoever takes over the role can see what they must do. If a policy names one person, it can quickly become out of date and leave a recovery action with no clear owner.

An example of assigned roles

A small online shop selling board games could set out responsibilities like this:

Assigning each task to a specific role makes someone accountable. It also prevents the same action being duplicated by several staff or forgotten because everyone assumes another person is handling it. With vague responsibilities, staff may all try to restore the same database while nobody checks the payment system.

Staff instructions are the part of a disaster recovery policy that tells everyone what to do, and what not to do, as soon as a serious incident happens. Clear instructions stop people acting on guesswork and reduce the risk of making the situation worse.

Immediate instructions

The policy should give simple, specific steps, so nobody has to decide for themselves what to do. Staff should not switch off or restart equipment, because data may still be in memory, an automatic backup may be running, or the recovery team may need to see the equipment exactly as it is. Staff should contact the named job role, such as the network manager, so there is no doubt about who to get hold of.

Staff should then report to the stated meeting point and sign in, so the recovery team knows who is on site and who is safe. Other dos and don'ts should be listed too, for example 'do keep clear of the affected area' and 'do not attempt repairs yourself'.

Why everyone needs to know

All staff need to know the procedures, even cleaners, receptionists and teachers with no recovery tasks of their own. They may need to get out safely, stay out of the way of recovery work, or follow instructions from the recovery team. For example, if a power failure shuts down the main building, a receptionist still needs to know where to report and who to contact, even though they will not restore any systems.

Training and reminders

Training and regular reminders, such as an induction session and a yearly briefing, help make sure everyone remembers what to do under pressure. People forget detail when they are panicking, so a short checklist kept with the emergency contacts supports this.

The disaster recovery policy defines the backup process in detail, so everyone knows exactly what happens and when. It should list the critical software applications, the critical data and the hardware needed to run them. Critical data is the information the organisation cannot function without, such as online shop orders or cinema ticket bookings, so it is backed up most often.

Different systems need different frequencies. A system that changes constantly and matters most should be backed up more often than one used only occasionally — a busy till system might be copied every 15 minutes, while archived records might be copied every three months. The policy must give these exact frequencies, not just say backups happen regularly, because staff need to know how much work could be lost. It should also give the schedule: the set time and day when each backup runs, such as 07:00 and 19:00 on weekdays or Saturday at 03:00, so backups do not clash with busy periods.

The policy should name the media or platform used, such as a dedicated backup server, and state where backups are stored, such as a secure data centre in another town, so a problem at the main site cannot destroy the copies too. It should also name the designated person or people responsible for backups, usually by job role such as the network manager, so the policy still works when staff change.

A recovery timeline is the part of a disaster recovery policy that states when each system and its data must be working again after a disaster. It turns recovery into a priority order, so staff know what to bring back first instead of treating every system as equally urgent.

The timeline gives each system a target time for being back up and running. It also records how long the organisation can manage without that system. These are not the same: a system can be important but still be missed for a day, while another stops work almost immediately. The target time should be shorter than the longest time the organisation could cope, so there is a margin for error.

An example timeline

Riverside Music Tuition lists its systems in order. Pupil records come first because tutors need contact and medical details before lessons can run safely. The public website comes last because nobody needs it to teach.

Critical systems are the ones the organisation cannot manage without for long. They are recovered first. A timeline that marks everything as urgent is useless because it gives no real priority.

Actions in order

The timeline should also list the recovery actions in the order staff should carry them out, with a time or trigger for each. For Riverside, the first actions might be to check that pupil records are available, then bring back card payments, then rebuild the rota, and finally update the website. Setting out the actions like this means staff know what to do and when, rather than wasting time deciding what to do next while under pressure.

If the main site cannot be used, the organisation still needs to keep working. The disaster recovery policy should identify an alternative location where operations can continue.

That location needs the right resources, not just empty desks. Alternative hardware must be able to run critical systems, alternative software and licences must let staff do their jobs, and alternative personnel (people with the necessary skills) must be available. Copies of the backups must also be on hand so data can be restored. If any one of these is missing, the organisation cannot function again quickly.

Plan ahead for access

Contingency plans for the alternative location should be made in advance. A key part is guaranteed access to the site: staff must be able to get in and start work without delay. For example, a group of music rehearsal studios names a partner studio across the city as its alternative location; the written agreement reserves two live rooms, and every member of staff's key fob already opens the partner building, with the fobs checked each year. Without this arrangement, staff could arrive and find themselves locked out.

Standardised hardware saves time

Using standardised hardware - the same makes and models throughout the organisation - makes it easier to replicate or reimage equipment at the alternative location. One standard image can be rebuilt onto any machine, so it behaves like every other one. Staff recognise the system straight away and parts can be swapped between machines, which is much faster than setting up lots of different models from scratch.

Specific policy wording means every instruction in a disaster recovery policy names the exact role, action, time and place it applies to, so staff never have to work it out for themselves. A policy that covers the right topics but words them vaguely looks complete, yet it is unusable at the moment it is needed.

Why vague wording fails

Vague wording causes two problems. Staff working under pressure take longer to decide what to do, and different people guess differently: one member of staff waits for instructions while another starts unplugging equipment, so recovery work is delayed or undone. Vague wording also cannot be checked, because nobody can say afterwards whether a paper booking was caught up with soon enough.

A specific instruction is a standard you can measure against, so the policy can be rehearsed, reviewed and improved, and any member of staff can be held accountable for their part of it. Words such as appropriate, promptly and suitable hide a decision that somebody has already had to make, so write that decision into the policy instead. A separate note covers the recovery timeline.