IT Service Governance and Reporting
Turn outsourced activity into visible accountability.
Senior-led service governance that connects operational performance, risks, changes and improvement priorities to business outcomes.
Based in Boksburg and supporting organisations across Gauteng: IT support in Johannesburg and IT support on the East Rand.
Discuss this managed service →Defined scope. Clear ownership. Visible service.
Senior-led service governance that connects operational performance, risks, changes and improvement priorities to business outcomes. Namandla Consultants begins with discovery, agrees responsibilities and measures the service against operational outcomes.
What the service can cover.
Service reviews
Review delivery, recurring issues, risks and priorities with accountable stakeholders.
SLA and trend reporting
Report performance and trends in language that supports decisions, not activity alone.
Risk and exception tracking
Maintain visibility of operational risks, unsupported assets and unresolved exceptions.
Change oversight
Coordinate planned changes, dependencies, approvals, communication and validation.
Supplier coordination
Bring third-party suppliers into incidents and changes while retaining end-to-end accountability.
Improvement roadmap
Maintain a prioritised plan for reliability, security, supportability and cost improvement.
Controlled from onboarding to improvement.
What governance is for
An IT service without governance is a monthly invoice and a hope. Governance answers four questions, and each one should be answerable from the reporting rather than from an opinion.
Are we getting what we agreed? Performance against the response commitments, scope delivered, work completed.
Is the environment improving? Ticket volume trend, recurring causes closed, patch and backup compliance and the direction each of them is moving.
What changed and who approved it? A record of changes made, by whom and under what authority.
What should we do next? A short list of things worth changing, with reasoning and cost.
The fourth is the one that makes a review worth attending. Reporting that only describes the past is a scorecard. Reporting that ends in a proposal is a decision meeting.
Monthly reporting
Service performance
Ticket volume by category and severity with trend. Response performance against target by severity. First contact resolution. Ageing and anything sitting unlooked-at.
Environment health
Patch compliance by asset class. Vulnerability position, opened and closed. Backup job success and the most recent verified restore. Monitoring alert volume and how much of it was actioned. Endpoint compliance.
Recurring causes
The issues that appeared more than once, what is understood about them and what is proposed. This is the section that turns reporting into improvement.
Changes made
What was changed, when, by whom, under what approval and with what result.
Capacity and consumption
Storage growth, bandwidth, licence assignment against entitlement, backup repository. Enough lead time that expansion is planned rather than urgent.
What we could not do
Blocked work, access we did not get, decisions waiting with you. Omitting this section is common and it is how a provider ends up reporting green while three things are stuck.
Quarterly service review
Ninety minutes, with the people who can decide.
Trend across the quarter rather than the month. Single months are noisy and a quarter shows direction.
Problem records opened, closed and outstanding, with the effect of the closed ones visible in the volume trend.
Risk and exception register
What is unpatched and why, what is out of support, what has been risk-accepted and when each was last reviewed.
Scope review
What has changed in your business, what is coming and whether the agreement still fits. Estates grow and agreements do not follow unless someone looks.
A short recommendation list
Three to five items, each with reasoning, effort and cost. Not a roadmap. A roadmap is a document nobody reads. Three items with a decision against each is progress.
Change control
Proportionate rather than bureaucratic. Three categories.
Standard changes are pre-approved, low risk and repeatable. New user, software installation from the catalogue, routine patching within the agreed window. Logged, not approved individually.
Normal changes need assessment and approval before implementation. Configuration changes, new systems, anything affecting multiple users. Documented with a rollback plan.
Emergency changes address a P1 or an actively exploited vulnerability. Implemented first, documented and reviewed after, through a path defined in advance rather than invented under pressure.
Every change carries an implementer, an approver, a rollback plan and a post-implementation check. The rollback plan is the part most often omitted, and it is the part that matters when a change goes wrong at 16:45 on a Friday.
Asset and configuration records
Maintained rather than rebuilt annually. A record assembled once a year for an audit is out of date before the audit finishes.
What it holds: hardware and its lifecycle position, software and licence entitlement against assignment, network devices and their configurations, service accounts and what they are for, certificates and expiry dates, third-party contracts and renewal dates, and dependency relationships between systems.
The dependency map earns its cost during recovery. It is where you find the licence server nobody knew about and the scheduled task on a workstation under a desk. Building it is unglamorous and it is what makes recovery predictable rather than exploratory.
What Namandla delivers
Monthly reporting to the structure above. Quarterly service review, facilitated, with a recommendation list and decisions recorded. Change control appropriate to your size. Asset and configuration record maintained as part of the service. Risk and exception register with owners and review dates. Documentation kept current, including recovery runbooks and network diagrams. Support for audits, customer security questionnaires and insurance applications, since the evidence is a by-product of the reporting rather than a retrospective assembly exercise.
Remote delivery nationally. Reviews in person in Gauteng or remote, whichever suits.
Common questions about Service Governance & Reporting
What should an IT service report contain?
Performance against agreed targets, environment health across patching, backup, vulnerability and endpoint compliance, recurring causes with what is proposed about them, changes made, capacity trends and anything blocked.
The test of a useful report is whether it supports a decision. A report that lists tickets closed tells you the provider was busy. A report that shows volume falling because three recurring causes were removed tells you the environment is improving, and those are different claims.
How often should we review the service?
Monthly reporting, quarterly review with the people who can make decisions. Monthly review meetings are usually more frequent than the data justifies and they turn into status updates.
A quarter is long enough to show trend and short enough to act on. The exception is the first six months of a new arrangement, where monthly reviews are worth it while the baseline is being established and the early findings are being worked through.
What is change control and do we need it?
Change control means changes are assessed, approved, documented and reversible. It should be proportionate: pre-approved standard changes, assessed normal changes and a defined emergency path.
Every organisation needs the emergency path defined in advance and every change needs a rollback plan. Beyond that, scale it to your size. A twelve-person approval board in a hundred-person organisation is theatre and it produces workarounds, which is worse than no process because the changes still happen and now they are invisible.
Why does an asset register matter?
Because you cannot secure, patch, license or recover what you do not know exists. Every one of those disciplines depends on an accurate inventory and each of them fails quietly at the edges.
The dependency map inside it is the part with the highest return, and it pays out during recovery. It is where the undocumented dependency is found, and finding it during a planned exercise is considerably cheaper than finding it during an actual recovery.
Can you support our audit or security questionnaire?
Yes. Patch compliance, vulnerability remediation, backup and restore evidence, access control and change records all come out of the standing reporting.
This is a practical benefit that gets undersold. Customer security questionnaires and insurance applications ask for exactly this evidence, and assembling it retrospectively takes days of effort and produces a weaker answer than producing it monthly as a by-product.
What if the reporting shows you are missing targets?
Then it shows that. Reporting that only ever shows green is not being measured honestly, and it is worth being suspicious of.
Missed targets get an explanation and an action. Where the cause is on our side we say so. Where it is access we did not get or a decision waiting with you, the report says that too, which is why the blocked-work section exists.
Do we own the documentation?
Yes. Asset records, configuration documentation, runbooks and ticket history are yours and they are exportable at any point, not only at exit.
Confirm this with any provider before signing. Documentation and ticket history that cannot leave the provider’s platform is a real constraint on ever changing provider, and it is a question far more easily asked at the start than at the end.
When is formal governance more than you need?
On a small environment with a single site and low change volume, monthly reporting and an annual conversation is proportionate. Quarterly reviews and formal change control add structure that the volume does not justify.
What is worth doing at any size is keeping an accurate asset list, recording changes somewhere and having one honest conversation a year about whether the arrangement still fits. Those three cost almost nothing and they cover most of what governance is actually for.