Support Regulation for Maintenance: Preventive Work and Reporting

Why have a regulation if there is already a contract and SLA

Contracts and SLAs usually answer one main question: how fast support will start responding and when the service will be restored. That is important, but not enough. You can perfectly meet "response times" and still keep encountering the same failures every month because no one agreed on preventive work, checks, and the change process.

A support regulation is needed for something else. It describes what the team does regularly, how it records changes and how it shows results. Without such rules, support quickly becomes firefighting: someone asks to update a server, someone suddenly changes settings, reports appear only after incidents.

Managers usually don't need a technical diary. They need a clear picture: what is planned, what is done, where the risks are and how much it costs in hours or money. The regulation makes this possible by setting a unified format for planning and reporting.

A good regulation answers simple questions from day one:

• which regular tasks are performed and with what frequency (patches, backups, monitoring, capacity checks);
• when changes can be made and who approves them so there are no "surprise changes";
• how risk is assessed and how we roll back if something goes wrong;
• in what form management receives reports: status, deviations, causes, action plan.

Example: in an organization with dozens of workstations and a couple of servers everything "works" until an update arrives that conflicts with a driver or policies. The SLA will help quickly accept the ticket, but the regulation establishes the maintenance window, testing on a small group and a clear post-change report. This reduces downtime and removes surprises.

Glossary and scope: what exactly we support

For a support regulation to work, first agree on terms and boundaries. Otherwise the same request will be called different things and expectations between IT and the business will diverge in the first week.

The approach is simple: describe what you consider a service, what it consists of, who is responsible for what, and how changes are recorded.

A mini-glossary that removes 80% of disputes

• Service: a business-facing service with a result (for example, "corporate mail" or "office network"), not an individual server or license.
• Component: a part of a service (PC, switch, server, virtual machine, user account) to which tasks and records can be assigned.
• Owner: a person from the business who confirms the need and acceptable form of the service and approves changes.
• User: someone who works with the service and creates requests via the agreed channel.
• Change: any action that may affect the service (update, migration, new configuration, hardware replacement).

Next, fix boundaries of responsibility: who performs tasks, who approves (usually the service owner), who accepts the result (owner or an authorized person). Also note what is out of scope: for example, "personal employee devices" or "proprietary reports without an owner."

Set criticality using a simple 3-level scale: critical (stops the business), important (interferes with some users), low (doesn't affect the core process). Use it for prioritization and scheduling, not for arguments.

Finally, define a single intake for requests (one channel and one format) and the rule: all changes and agreements are recorded there. Then management reporting is built from facts, not from scattered chats.

A short example: if the company has workstations and servers (including locally produced equipment), specify where support responsibility ends (configuration and updates) and where the supplier/contractor zone begins (warranty replacement, capacity upgrades).

Catalog of regular tasks: what we do daily, weekly, monthly

The catalog of regular tasks is the core of the support regulation. It answers a simple question: what do we do in advance so we don't spend time firefighting. For each item record the owner (role), expected time, where the result is recorded and the success indicator.

Start with groups of tasks that repeat in almost any infrastructure: preventive maintenance, monitoring, backups, security and documentation updates. It is important to write verifiable actions: what exactly to check, where, and how to understand that everything is normal.

How a schedule looks

It is convenient to separate tasks by period and briefly note the expected outcome:

• Daily: check status of key services and alerts, check free space on critical disks, verify nightly backups succeeded, handle simple recurring requests (e.g., disabling a lost account).
• Weekly: selective review of security logs, reconcile list of administrators and permissions for shared resources, check antivirus signatures and agent presence, clean temporary files on servers.
• Monthly: scheduled OS and application patches within the agreed scope, review security policies (passwords, locks, access), inventory configuration changes on key nodes, consolidated incident and risk report.
• Quarterly: test restore from backup for a chosen scenario, check UPS and disk health, audit licenses and certificates, update diagrams and contact lists.
• On event: after any change record what changed, where, who approved it, and update instructions (for a new service version or new server).

Minimal artifacts to ensure transparency

So management can see real work, each task should leave a trace: a work log entry, a short note of what was checked, and an attached result (metric screenshot, backup log, updated document without external links). Then preventive work becomes measurable, not "done by word of mouth."

How to set frequency and scope without overload

Choose task frequency not by habit but by service criticality, downtime risk and actual availability of people. Errors are costlier for accounting and domains than for a test environment. If the team is small, better not to promise too much than to create a nice but unachievable schedule.

A practical method: for each regular task answer three questions — what happens if it's skipped; how quickly will it be noticed; how long will repair take. The higher the risk and the harder the recovery, the shorter the interval.

For a start, use an MVP set of frequencies so the regulation works without suffocating the team:

• Daily: check backups and key alerts.
• Weekly: check free space, basic account hygiene.
• Monthly: OS and application patches in an agreed window.
• Quarterly: test restore from backup, review access rights.
• Twice a year: inventory and update diagrams, contacts, instructions.

Estimate effort in hours and record assumptions. Count the full cycle: preparation, execution, verification, logging. If "monthly updates" on the server fleet take 8 hours including access and window setup, state that rather than "1 hour" to look better.

To tie everything to the calendar, use a simple rule: each task has an owner, a backup executor and an exact day (for example, "second Wednesday of the month, 20:00–22:00"). In environments with local servers and workstations (typical for public sector) patches are convenient to plan in the same evening window, and the execution report goes out the next business day. Then the schedule becomes a habit, not heroic one-offs.

Maintenance windows: planning changes without surprises

A maintenance window is a pre-agreed time when changes can be safely made: applying updates, changing settings, migrating services, checking backups. The difference from emergency work is simple: an emergency starts outside the plan and needs immediate action, while a window exists to reduce emergencies.

To include windows in the regulation, define short rules for planned changes. Every change should have a clear package: who does it, what is changed, what the risks are and how to roll back if needed.

Usually record: notification (when and whom we warn), approval (who gives final "ok"), work plan (steps and expected result), rollback plan (what to do on failure) and success criteria (how we know everything is fine).

Then set constraints. Many organizations have forbidden days (month-end close, reporting, enrollment, exams) and critical hours when outages are unacceptable. Describe these periods in one paragraph and update them quarterly rather than keeping them in people's heads.

Communication should be short and consistent each time: what will change, when, possible effects, where to report issues. For example, when updating accounting servers notify accountants, the department head and the service desk in advance so requests during the window don't look like "unexpected failures."

After each window record what was done, outcomes, time spent, whether rollbacks occurred, what risks were found and what to improve next time.

Change control: a simple process that works

Change control exists not for bureaucracy but to make interventions predictable: who requested, who did it, who approved, what could go wrong and how to restore. Put a short mandatory process into the support regulation.

Start with roles and capture them in one paragraph. The initiator explains the need and expected result. The executor proposes the work plan. The approver confirms acceptable risk (usually IS, application owner or department head). The service owner is responsible for whether and when the change can happen.

Use a simple template so requests don't become long threads. It should include only key fields:

• purpose of the change (what improves and for whom);
• impact (which systems and users are affected);
• risk and checks (what might break and how we will notice it);
• execution plan (steps and maintenance window);
• rollback plan (how to revert).

Classify changes into three types. Standard changes follow pre-approved instructions (e.g., scheduled antivirus signature updates) and are approved once. Normal changes require one-time approval before each execution. Urgent changes are allowed only to restore service and must be documented afterward in the log.

Agree rules for "small" edits. A common trap: they are done "in a minute" and then nobody remembers why a parameter changed, complicating incident analysis. Rule: if a tweak changes system behavior, record it even if approval is simplified.

Keep a change log as a single list: date/time, what changed, who did it, link to the request, verification result. If an incident follows a change, record the related incident. Example: after a firmware update a rack server began to reboot more often; the log shows which change started the problem and what rollback was planned.

Transparent reporting for management: format and content

Reporting in a support regulation is not a formality. It helps management understand three things: what changed, where downtime risks exist and what you are doing proactively. The best format is one page in plain language, without internal jargon or ticket threads.

Weekly status (10 minutes to read)

A weekly report is useful when it reads like a short state overview, not an event log. Often one table or a four-part block is enough:

• Done this week: 3–5 notable tasks.
• Deviations: what went off plan and why (with time and user impact).
• Risks: what might "blow up" in the next 1–2 weeks and what you are already doing.
• Plan: what will be done in the next maintenance window and what approvals are needed.

Add one line about the effect of preventive work: "checked UPS — found a battery near end-of-life, will replace before outage season." That text explains value better than "closed 47 tickets."

Monthly report (for decisions)

The monthly report aggregates the picture and helps set priorities. Keep 4–5 metrics and short conclusions:

• availability of key services and causes of downtime (facts and lessons, no blame);
• changes: what was implemented, rolled back or postponed and why;
• technical debt: 3 main open items, deadline and cost of inaction;
• vulnerabilities and updates: what was closed, what remains, and any approved exceptions;
• preventive effect: prevented incidents, fewer repeats, shorter recovery times.

Example: in a branch network the report might show that after cleaning logs and updating drivers on workstations there were fewer intermittent freezes. The risk is outdated software on 12 machines, which will be scheduled next month.

How to create the regulation in 10 steps

A support regulation is convenient as a short but complete document: what we support, what regular tasks we do, how we manage changes and how we report to management.

1. Compile a list of services and components (workstations, network, servers, applications).
2. Assign owners: business owner (who accepts the effect) and technical owner (who is responsible for status).
3. Fix boundaries: what is included, what is excluded, and dependencies on external suppliers.
4. Describe regular tasks in simple terms (checks, updates, backups, monitoring).
5. Create a calendar: frequency, expected duration, required access and windows that cause no downtime.

Next, agree on predictable changes to avoid sudden interruptions and disputes.

6. Approve maintenance windows: days/times, emergency work rules, who gives approvals.
7. Define notification rules: how many hours/days in advance, to whom, with what text, and what counts as confirmation.
8. Introduce a change log: what changed, why, risk, rollback, who executed, and final result.
9. Create change request templates (short fields, no bureaucracy) and assign reviewers.
10. Set up reporting and meeting rhythms: 15–30 minutes weekly or biweekly, plus a monthly report for management.

Example: if you support a fleet of PCs and servers, record in advance which updates are safe during the day and which require a night window, and always log the rollback. This greatly reduces unexpected incidents and increases trust in IT.

Typical mistakes and how to avoid them

The main problem is writing the regulation as a formality. The document exists, but predictability does not. Common mistakes and how to avoid them:

• Vague wording instead of specifics. If text only says "support and administration," everyone interprets it differently. List regular tasks by system and frequency, and explicitly note what is out of scope.

• No service owner and approval chain. If no business and IT owners are assigned, decisions stall and changes happen without control. Specify the service owner, responsible executors and approvers for plans, changes and final reports.

• Maintenance windows are not fixed and keep changing. When updates happen "when possible" it surprises users. Fix regular windows, emergency rules and how you warn departments (lead time, channel, notification template).

• Reporting becomes a dump without conclusions. A long ticket list doesn't help management decide. Give the report structure: 3–5 key metrics, what improved or worsened, causes, risks and a concrete plan for the next period.

• No rollback plan or success criteria. After a failed update the team wastes hours firefighting. Describe how results are checked, who signs off on production, and steps to rollback and target recovery time.

If an integrator runs support, include these items in the regulation so both client and vendor follow the same rules without disputes.

Short readiness checklist for the regulation

Before launch, test the regulation: can a new hire work from it without clarifying questions, and can a manager understand IT state from one report?

Check these. If any answer is "no," fix the document before launch.

• There is a clear catalog of regular tasks: what is done daily/weekly/monthly and who is responsible (role and backup).
• Maintenance windows are defined: when planned changes are allowed, who and how far in advance is notified, what counts as an emergency.
• There is a single change request template: purpose, affected systems, risk, verification plan and mandatory rollback plan.
• Reporting is predefined: what goes into the weekly report (incidents, availability, completed tasks, risks) and what is added monthly (trends, recurring causes, work plan, resource needs).
• Contacts and escalation are recorded: who makes decisions in incidents, channels, expected response times, and next escalation steps.

Also check backups specifically. The regulation must not only say "backups are performed" but include restore check schedules: what is restored, how often, who records results and where the protocol is stored.

If the checklist is complete, the regulation typically works without excessive bureaucracy: the team knows what to do, changes are predictable and management gets a short honest IT status.

Example scenario: office infrastructure without extra bureaucracy

A company with 200 workstations. Two servers in the server room (files and domain, plus 1C/accounting), Wi‑Fi, printers, and backups. Main users are accounting (deadlines critical) and sales (mail, CRM and file access critical).

The regulation in such an office doesn't need to be long. A clear maintenance calendar and pre-agreed windows are enough to avoid sudden changes.

A realistic calendar:

• Daily: check backup success and free disk space on servers (10–15 minutes).
• Weekly: check antivirus events, updates on 10–20 test PCs.
• Monthly: update servers in the agreed window, test restore from backup.
• Quarterly: inventory equipment and license accounting.
• As needed: replace consumables, check UPS and server room temperature.

Example change: update the OS on the server running 1C. Simple plan: on Thursday submit a request with reason (vulnerability fix), risk estimate and downtime. The accounting manager approves the window: Saturday 22:00–01:00. Before start take a snapshot/backup, check space, record current versions. During the window perform the update, reboot, run a quick test (login to 1C, print, exchange). If tests fail within 30 minutes start rollback: restore snapshot, bring service up and reschedule the work.

At the end of the week management receives a short one-page report:

• Availability of key services: no downtime during working hours.
• Maintenance: backups checked, test restore successful.
• Changes: server 1C update prepared, window agreed.
• Incidents: 3 printer tickets resolved within a day, no repeats.
• Risks and actions: one disk in RAID declared warning, ordered replacement.

What improved: accounting knew about the window and didn't plan filing overnight. Sales did not lose file access mid-day. IT spent less time explaining and rolling back because the process and report were clear for everyone.

Next steps: how to launch and embed the regulation

To make the regulation more than a paper exercise, start with facts. A short inventory clarifies what systems exist, who owns them, what is critical and where responsibility boundaries lie (IT, contractor, supplier).

Create an MVP of 1–2 pages without complex wording. It should include: list of regular tasks, maintenance windows, a simple change process and one report format for management. That's enough to start the cycle and reveal gaps.

A rollout approach that usually works:

• Collect current data: systems list, owners, criticality, contacts and access for tasks.
• Approve the MVP and run a one-month pilot, recording deviations and questions.
• After the month add what was actually needed: missing regular tasks, quality criteria, metrics and report fields.
• Lock a single procedure: who approves changes, how windows are scheduled, where the change log and reports are stored.
• Set a quarterly review date and decide who will propose updates.

A small example: in office infrastructure people often forget UPS maintenance, firmware updates for network gear and restore verification. A one-month pilot quickly shows where gaps lead to incidents. After the pilot add these items to the regulation as regular tasks with clear frequency and owners.

If the team lacks time or experience, you can involve a system integrator to set up support processes and reporting, for example GSE.kz (gse.kz). The important part is the result: not a "project for the sake of a project," but a clear order of work and support that is actually followed.