From requirement list to framework
It usually starts with a document: a group policy, a security annex to a customer contract or a questionnaire a customer sends every year. This document becomes a custom framework when you transfer the individual requirements into controls.
It has proven useful to capture one requirement per control. If a paragraph contains several obligations, for example on encryption, logging and retention, split it up. Only then can you later show a separate status and separate evidence for each obligation. Use the numbering of the source as the identifier. Then you and your customer are talking about the same requirement.
Phrase each control as a question that can be checked. The obligation to ensure appropriate security, for example, becomes the question of whether customer data is encrypted in transit. Clarify unclear requirements with the customer before you answer them.
If the requirement list already exists as a spreadsheet, you do not need to type it out. Sightadel supports import from Excel and Word files. Afterwards, check the imported items one by one for splitting and wording.
Reusing existing work
The greatest benefit of a custom framework comes from linking. Many customer requirements call for things you already implement for ISO 27001, NIS2 or the GDPR: access control, backup, training, incident handling, processing on behalf. The proof for these is already in the evidence archive.
So go through the custom framework first with an eye on what already exists. Where a requirement is backed by evidence, link it. The evidence is maintained in one place, and if it expires, you see this in all frameworks at once.
Check carefully whether the evidence really meets the customer requirement. Customers often phrase things more strictly or more specifically than a standard. If a contract requires, for example, a specific deadline for informing the customer about incidents, a general incident handling process is not enough. In that case you add to the process and the evidence.
What remains open after that are the real gaps. You answer them honestly in the assessment and create action plans. This gives a clear picture of what you need to do in addition for this customer.
Custom frameworks for customers and auditors
A custom framework is not a standard against which certification takes place. It is a working tool that lets you show customers, the parent company or your own management how far you meet certain requirements.
When a customer asks, you show the status, the answer and the proof for each of their requirements. This is good preparation for a supplier audit by the customer, because the structure follows their own list. Check any proof you want to pass on for confidential content beforehand.
A custom framework can also play a role in the certification audit. ISO 27001, for example, requires you to take into account the requirements of interested parties, and these include contractual requirements from customers. With the “External auditor” role, the auditor sees the content, including custom frameworks, and can comment on it. They can never delete anything.
The same applies to internal audit checklists, such as an annual self-assessment of your sites. You create the assessment with a responsible person and a due date, the people involved answer the controls, and progress is visible in one place.
Common mistakes when setting up
The most common mistake is a custom framework for something that already exists. Check the list of standard frameworks before you create one. Sightadel includes ISO 27001, ISO 9001, ISO 42001, NIS2, GDPR, BSI C5, DORA, NIST CSF 2.0, SOC 2, HACCP, § 390 SGB V (German Social Code, Book V) and the EU AI Act.
A second mistake is too coarse a structure. A control that bundles five obligations can only be answered as a whole. Part of it is met, part is not, and the answer becomes vague. Better to split it up.
Third, maintenance is often missing. Customer requirements change with every new contract, group requirements with every new version. Decide who keeps the framework up to date, and record which version of the source it is based on.
Fourth, a custom framework is not useful for every customer. If the requirements of several customers are very similar, a shared framework with the strictest requirements of each can be clearer. The number of custom frameworks also depends on your edition.
