Managed-service teams are in an unusual position: they run other people’s systems, so every customer audit eventually reaches them. Questions arrive about who touched production, how quickly leavers lose access and whether last month’s patch cycle really happened. ComplianceOps gives support teams a way to answer from records instead of recollection. Here are eight habits, in the order we would introduce them to a new service desk.
1. Keep a register of what each customer was promised
Start with the contract, not the tooling. For every account, list the commitments that touch your work: response targets, access rules, reporting duties, and any security questionnaire answers the customer has relied on. The Ops Atlas entry on ComplianceOps places this obligation inventory first among the discipline’s responsibilities, and for support providers it doubles as a clear picture of what is owed to whom.
2. Build one control library, not one per customer
Customers use different words for the same requirement. Rather than creating a bespoke checklist for each, maintain a single library of controls and record which customer or framework requirement each one answers. A control such as “access reviewed every quarter” can satisfy a six-month payment rule and an annual New York cybersecurity rule at once, with ISO 27001 naming no interval. The mapping must say which requirement is met, otherwise a note that a control “covers three requirements” loses the detail an auditor will ask for.
3. Give evidence a shelf life
Every record needs four attributes: its source, capture time, method and the test it supports. Then add a maximum age. A ticket export is acceptable for thirty days, a customer sign-off for ninety, for instance. Past the limit the record counts as missing. This rule alone prevents the classic situation in which a tidy folder describes the world as it was a year ago.
4. Treat the exception as a loan, not a gift
Support teams negotiate exceptions all the time: a legacy server that cannot be patched, a contractor who needs temporary access. Record each one with the exact resources affected, the reason and an end date. When the date passes, the exception expires and the control fails again. The Atlas warns against renewing to green, meaning extending an expired exception without any compensating safeguard so the report looks healthy.
5. Automate what repeats, and report what is not automated
Collect user lists, patch states and backup confirmations on a schedule. Report the share that is automated alongside the share that is fresh and the number of controls never tested. The Atlas places the threshold for its third maturity level at more than half the controls automated, with nothing stale when an audit period begins. Honest reporting also means being able to say a number is poor.
A word on cadence. The Atlas notes that NIST’s idea of continuous monitoring means often enough to support risk decisions, not live streaming. For a service desk that might be a nightly user export and a weekly patch summary. Choose the interval by asking how quickly the underlying fact can change, write that reasoning next to the control, and revisit it when the environment shifts. Over-collecting costs storage and attention, while under-collecting leaves gaps nobody notices until an audit.
6. Own the vendor reports you depend on
Your own customers read your assurance reports; you read your suppliers’. Two details deserve attention. Those reports list user-entity controls that you, as the customer, are expected to operate. And a bridge letter from a supplier’s management covers the gap since its last report but has not been validated by an auditor. Support teams that notice these details avoid unpleasant surprises during customer reviews.
Role clarity helps here, which is why our guide to understanding role titles, career paths and job roles is a handy reference when deciding who in the team owns supplier reviews versus daily evidence collection.
7. Write the gap runbook before you need it
Eventually a record will be missing: a log rotated early, a screenshot never taken. The runbook should state three rules. Never back-date anything. Reconstruct the record and label it as a retrospective item with the date it was gathered. Tell the auditor or customer. Teams that practise this calmly find that disclosure is received far better than a patched-up story, and the habit protects every other record’s credibility.
8. Rehearse before the real thing
Run a dry audit each quarter. Pick three controls at random, ask a colleague who did not build the evidence to find it, and time the exercise. Add one deliberate break, such as a disabled collector, to see whether your tests notice. This rehearsal turns the abstract idea of audit readiness into a routine you can measure.
These habits fit comfortably with the broader operating principles described in our post on principles that make software delivery effective: shorter feedback loops, shared ownership, and visible work.
Traps support teams fall into
- Fixing problems in a rush before an audit and letting them lapse afterwards.
- Giving each framework its own team, so engineers answer the same question repeatedly.
- Amending an existing record rather than adding a newer one that supersedes it.
- Writing tests that check less than the requirement says, so a document that exists passes for a rule that is enforced.
- Opening the reporting period before every collector is connected.
Keep expectations realistic
A clean report does not prove that a system is secure. A certificate speaks to controls that operated on sampled days, and a well-known 2013 retail breach shows that an organisation can hold a recent assessment and still suffer a serious loss. Automated evidence changes what an auditor samples without removing the auditor, and no model-written summary should ever be filed as proof that a control ran. This article is general information and not legal advice or a guarantee of any assessment outcome.
