Client work comes first, and that's no different at a small company. Left alone, improving your own way of working slips another month every month. So we have a fixed rhythm: short weekly moments to adjust course, and once a month a full day devoted to quality and security.
The weekly rhythm around it
The week starts with a short kick-off: what's planned, where the company stands and which actions are high priority. Each project has a sprint meeting to discuss what was done, what's blocked and what still needs refining. There's also a weekly code review: one colleague presents a few recent pull requests, we discuss content and style, and whatever we learn gets applied to all codebases.
Someone takes notes at every meeting, and we agree beforehand who. Our rule is that half sentences with the right content beat polished sentences that miss half the discussion. You can always tidy up notes later; you can't recover what you never wrote down.
The Quality and Security Day
On the last Friday of every month we take a day for quality and security. The standing agenda:
- look back at security incidents and how we responded;
- go through logging and monitoring;
- walk through the action points from earlier notes;
- check the register of non-conformities;
- review the roadmap and choose what to work on this month.
Some topics have their own frequency:
| Frequency | Topics |
|---|---|
| Every three months | Access matrices, gap analysis |
| Every six months | Risk assessment, asset registry, continuity plan and objectives; plan the internal audit and management review |
Improvements with an owner
Improvements come from everywhere: an incident, a client remark, a new risk, a new legal requirement, or something a colleague noticed. They go on the roadmap, get an owner and are reviewed every month. We prioritise by business impact, feasibility and risk.
Two terms come up a lot:
- Non-conformity: something that doesn't go as agreed, either because we didn't do it properly or because the agreement no longer fits how we work.
- Corrective action: what you do to remove the cause, not just repair the consequence.
Internal audits
At least once a year we run a full internal audit of how we work. For information security we use an assessment framework that rates each area on a maturity scale. For quality we use a checklist, and for projects where personal data plays a big role a privacy impact assessment may also be needed.
You go through the checklist step by step, judge whether what's written down actually happens, and record the evidence. When an area reaches a certain level, we also write down what it would take to reach the next level and whether that's easy or hard. That feeds straight into the roadmap.
We then have the completed result validated by someone independent of top management. You rarely judge your own work fully honestly: you know what you meant, so you fill in gaps automatically. After a major change or incident we sometimes run a smaller audit on that one theme. We also check whether the suppliers of our software services still meet security standards and whether we want to keep them.
In practice: when an area reaches a certain level, we also write down what it would take to reach the next level. That gives us direct input for the roadmap. After a major change or incident, we sometimes run a smaller audit on that theme. We also check whether our software service providers still meet security standards and whether we want to keep them.
Management review
At least once a year, top management holds a formal review of the quality and security of the company as a whole. The agenda is fixed: the status of earlier actions, changes in our environment and in stakeholder expectations, trends in non-conformities, measurements and audit results, client feedback, the state of our risks and opportunities to improve. The outcome is decisions, actions and agreements on time and resources.
Follow-up and records
For a non-conformity we define a corrective action with a deadline, record what we did and check later whether it worked. Notes, roadmap, audit reports and actions are kept under version control, so you can see what we decided and whether it had an effect. We don't want more paperwork than that.