What A.5.12 classification of information asks for and why auditors check it
If you have to show an assessor a working classification scheme, the question is whether your organization sorts its information into levels that actually drive how people store, share and dispose of it. A.5.12 asks for information to be classified according to the organization's own information security needs, judged against confidentiality, integrity, availability and the requirements of relevant interested parties such as customers, regulators and contracts. In plain terms, the organization decides how sensitive or critical each kind of information is, records that decision in a scheme with defined levels, and then uses those levels to set the protection the information receives. The control is an organizational one, so the organization owns the scheme and its level definitions, and an auditor will test whether the scheme exists, is approved, and is applied. The requirement carries forward the 2013 control A.8.2.1 Classification of information, and ISO/IEC 27002:2022 gives the implementation guidance for it. Read that guidance alongside the standard's own wording, because it is the practical reference for what a credible scheme contains.
Classification is hard in practice for three reasons that auditors look for. The first is labels that exist only on paper: a policy lists levels such as Public, Internal, Confidential and Restricted, but no system, template or repository shows them, and staff cannot say which level applies to a spreadsheet they just created. The second is inconsistent levels across teams, where finance, engineering and sales each use different names or thresholds for the same kind of data, so a customer contract and an internal report are protected differently for no documented reason. The third is no link to the asset inventory. Under A.5.9 the organization records information and its owners, and A.5.12 only works if each recorded asset carries its level. A practical first check is to pick five information stores at random and ask the owner what level applies, who approved it, and what handling rule follows from it. The answers show whether the scheme drives handling or sits in a policy document.
Plan for the work to be ongoing rather than a one-time exercise. Decide who assigns levels (usually the information owner, with a security function setting the criteria), how a level is reviewed when data changes, and which handling rules each level triggers under related controls such as A.5.10 acceptable use, A.5.13 labelling and A.8.12 data leakage prevention. Confirm with your certification body and your own legal team how the scheme maps to any sector rules you must meet, since a classification scheme is your own design and no standard fixes the level names for you. Then record the decisions. The evidence an assessor usually asks for is the approved scheme, the criteria behind each level, a sample of classified assets with their owners and levels, and records showing the scheme was reviewed. A scheme that is current, consistently applied and traceable to the inventory is what an auditor can test.
Which information and systems fall under the classification scheme
Classification only works when the scheme covers the places information actually lives. The decisions below determine which information types, repositories, SaaS tools and third parties sit inside the classification scheme, and they set the boundary that the ISMS scope draws around them.
Information types in scope
Start by listing the information types the organization handles: customer data, source code, financial records, personal data and internal documents. Each type needs an owner and a sensitivity judgment based on confidentiality, integrity and availability. A.5.12 asks for classification against the organization's own security needs, so the list should come from business process owners, not only from IT. Confirm that every type feeding the ISMS appears once, with a named owner.
Repositories and file stores
Shared drives, document wikis, ticketing attachments, backups and developer repositories all hold classified information. Each store should be mapped to the highest level of information it may contain, and the mapping should be checked against what is actually stored, not what policy says. A wiki page that copies customer records is in scope even if the wiki was set up for internal notes. Ask who can change the classification of content in each store.
SaaS tools and collaboration platforms
Email, chat, CRM, HR and document collaboration services often hold the most sensitive records without appearing in asset registers. Each platform needs a classification ceiling, a list of administrators and a record of which data types are permitted. Where a tool is self-hosted inside the organization's own infrastructure, its hosts and databases fall inside the scheme in the same way. Confirm that SaaS subscriptions are reconciled against the inventory at least once a year.
Third parties that receive information
Any supplier, contractor, auditor or hosting provider that receives classified information extends the scheme to their handling. The classification level should travel with the data into supplier agreements, transfer procedures and offboarding steps. Confirm which third parties hold data at each level and whether their contracts state how that data must be labeled, stored and returned. Relevant controls include A.5.19 and A.5.20.
ISMS scope as the boundary
The scope statement of the ISMS determines which business units, locations, systems and information flows the classification scheme must cover. Information outside the scope may still be classified for internal use, but an assessor will test the scheme only against the scoped boundary. Write the scope so that every information type identified above either sits inside it or is documented as excluded with a reason. Review the scope whenever a new product, site or customer data flow is added.
Exceptions and mixed-content records
Some records combine levels, such as a customer contract that includes pricing and personal data, or a source repository that holds a test key. Decide in advance whether such records take the highest level present, are split, or are redacted before sharing. Record the rule and the owner who may approve an exception. Auditors often sample these edge cases because they reveal whether the scheme works in practice.
How an assessor tests information classification
This table sets out what an assessor checks for A.5.12, the evidence they request for each check, and the findings they most often raise. Read it as a test plan: each row is a question the assessor asks, and the evidence column shows what the organization should have ready before the audit starts.
| Assessor check | Evidence requested | Common findings |
|---|---|---|
| Review of the classification scheme and its approval | Written scheme with defined levels, criteria for each level, the approver and approval date, and the version history | Scheme exists only as an informal list; no named approver; criteria too vague to apply consistently |
| Sampling of documents and systems to check the assigned level | Sample of files, mailboxes, shares and system datasets with their recorded level, compared against the criteria | Sensitive data carries no label; levels assigned inconsistently for similar content |
| Checking that the level drives handling rules | Handling standard per level covering storage, sharing, transfer, retention and disposal, plus examples of it being applied | Levels defined but never applied; handling rules exist only on paper or do not reach the teams that handle data |
| Checking that information owners are assigned | Register of owners for classified information or systems, with their acknowledgement of the role | Owners named for systems but not for datasets; owners unaware they hold the role |
| Checking the scheme against the asset inventory under A.5.9 | Inventory extract showing each asset with its classification and owner, reconciled to the scheme | Inventory has no classification field; assets missing from the inventory cannot be classified |
| Checking for conflicting schemes across departments | Schemes used by finance, HR, engineering and other functions, with any mapping to the organization-wide scheme | Departments use different labels for the same level; cross-department sharing relies on guesswork |
How to build a classification scheme that holds up to audit
This sequence turns the A.5.12 requirement into a working scheme: security criteria first, then a small set of levels, named owners, a tested sample and approved handling rules that people actually use. Each step produces a document or record an auditor can sample.
Define the security criteria for confidentiality, integrity and availability
Start by agreeing what each property means for your organization. Write a criteria matrix that describes, for confidentiality, integrity and availability, the impact levels that matter to the business, such as financial loss, regulatory exposure, customer harm or operational disruption. Add a column for interested party requirements, including contract clauses, regulator expectations and customer obligations that set minimum handling. Leadership or the ISMS owner should approve the matrix. It is done when every criterion is written in terms a system owner can apply without asking for interpretation.
Define a small set of levels with clear criteria
Translate the matrix into a short list of classification levels, each with a name, a plain-language definition and a test that decides which level a piece of information falls into. Keep the number of levels small enough that staff can remember them. Include a default level for information that does not clearly fit, and state who may lower a classification. The output is a level definition table with decision criteria. It is done when two reviewers given the same three example documents reach the same level.
Assign information owners
Name an owner for each major information set or system, and record the owner's authority to classify, approve access and accept risk. The owner decides the classification, while security and compliance staff review the decisions and maintain the scheme. This assignment links to the asset ownership expected under A.5.9 and to the role definitions under A.5.2. The output is an owner register that maps each information set to a named person and a backup. It is done when every entry in the inventory has an owner who has acknowledged the role.
Classify a sample of real information and inventory entries
Before approving the scheme, test it on actual material. Select a sample across file shares, collaboration tools, databases, backups and paper records, and classify each item against the draft criteria. Record disagreements, edge cases and items with no clear owner, then adjust the definitions. This step catches criteria that look clear on paper but fail in practice. The output is a classified sample with a log of decisions and changes. It is done when the sample is classified with no unresolved disputes, and the inventory entries carry the new classification field.
Link each level to handling rules and labelling
For every level, write the handling rules that follow from it. Cover storage, sharing, transfer, printing, disposal, use on endpoints and cloud services, and the approval needed for exceptions. These rules belong in the acceptable use material under A.5.10, and the marking method for documents, systems, metadata and media belongs under A.5.13. Keep the handling table short and tie each rule to a control that already exists, such as encryption, access review or data leakage prevention under A.8.12. The output is a handling matrix and a labelling procedure. It is done when each rule names the technical or procedural control that enforces it.
Approve, communicate and train
Obtain formal approval of the classification policy, the criteria matrix, the handling rules and the labelling procedure from the approver named in your ISMS document control process. Publish them where staff can find them, then brief information owners and the people who handle the most sensitive information. Record acknowledgements or training completion so you can show who received the rules. The output is an approved, versioned scheme with a distribution and training record. It is done when the approval is dated, the version is identified and the training records can be pulled for a sample of staff.
Review the scheme on a set cycle
Set a review cycle for the scheme and trigger reviews after significant changes, such as a new regulation, a merger, a new cloud platform or a classification incident. Each review checks whether the criteria still match business impact, whether the inventory classifications are accurate and whether handling rules are followed. Findings feed back into the criteria and the owner register. The output is a dated review record with decisions and version changes. It is done when the review record shows what was checked, who approved the outcome and what changed.
How classification drives handling rules and why the link is what gets tested
A classification level only protects information if it changes what people and systems do with it. For A.5.12, the test is whether each level maps to concrete handling rules for storage location, sharing, transfer, retention, disposal and access. The organization should write that mapping as a table: for each level, state where information may be stored, who may receive it, which transfer methods are allowed (linking to A.5.14 Information transfer), how long it is kept, and how it is destroyed. Keep the table short enough that a line manager can apply it without calling the security team. Confirm that the levels named in the scheme are the same words used in the labelling procedure under A.5.13 and the acceptable use rules under A.5.10, because a reviewer will notice when three documents use three vocabularies.
Access control is where the link becomes technical. A restricted level should translate into access groups or role assignments in the systems that hold it, governed by the access rules in A.5.15 and the access rights process in A.5.18. Data leakage prevention under A.8.12 is the control that tests the handling rule at the boundary: confirm which labels or content patterns your DLP tooling can read, which channels it monitors (email, endpoints, cloud storage, web uploads), and what it does on a match (block, warn or log). Where a tool cannot read a label, say so in the risk assessment and document the manual compensating step. Do not claim DLP coverage that the configuration does not show.
The asset inventory under A.5.9 is what makes the mapping traceable. Each information asset or repository should carry a classification and an owner in the inventory, so that a reviewer can start from a labelled document, find its repository and owner, and confirm the access groups, the DLP policy and the retention rule that apply to it. In a practical walk-through, an assessor picks a document labelled at the highest level, follows it to the system where it sits, checks who can open it, checks that a transfer attempt is controlled, and checks the disposal record at end of life. Self-hosted platforms can hold this chain together. For example, GLPI's Assets module can record owners and asset records, XWiki keeps version history for policy and register changes, and Wazuh's Syscollector inventory can confirm which systems hold what software, with the caveat that it does not read document classifications by itself. Confirm each of these capabilities in your own environment before relying on them as evidence.
Evidence that passes an A.5.12 review and how to keep it current
An assessor testing A.5.12 looks for a classification scheme that is approved, applied consistently and kept current. The six artifacts below show that chain from policy to inventory to handling rules, and each one needs a dated review rhythm and a change record so the evidence still matches reality between audits.
Approved classification policy or standard
This is the document that defines the classification levels, their meaning and who may apply them. An assessor checks that it was approved by someone with authority, that it names an owner and that it is the version the staff actually use. Keep one controlled version with an approval date, a next review date and a record of each change. Check that the approved text, the intranet copy and the copy linked from training material all match.
Level criteria matrix
The matrix sets out, for each level, the test that places information there, such as the impact of loss of confidentiality, integrity or availability and the interested party requirements that apply. Auditors look for criteria specific enough that two staff members would reach the same level for the same record. Review the matrix when business services, regulations or contracts change, and record which criteria changed and why.
Named information owner assignments
Each classified information set needs an owner who decides its level and approves exceptions. Auditors sample assignments and ask whether the named person still holds the role. Keep the owner register in your role or asset system, link each owner to the inventory entries they hold, and reassign records when people leave or move. An owner list that predates a reorganization is a common finding.
Classified inventory sample
Auditors choose items from the inventory and check that each carries a level that matches the criteria and an owner. Pick a sample of repositories, shares, databases and document sets, then compare their stated level with the actual access rights and content. Re-run the sample before each audit, record mismatches and the fix, and keep the date of the last reconciliation visible in the register.
Handling rules by classification level
A handling matrix states, for each level, the rules for storage, sharing, transfer, printing, disposal and use on personal devices. This is where classification becomes operational, and auditors test a few rules against real behavior. Confirm that the matrix matches the acceptable use and transfer procedures, and that each rule has an owner who reviews it on a fixed cycle.
Review records with version history
Assessors expect proof that the scheme was reviewed on schedule and that changes were tracked. Keep a dated review log for the policy, matrix and handling rules, with the reviewer, the outcome and the version compared with the previous one. A wiki with page history can supply this record, provided that approvals are captured and not only edits.
What meeting A.5.12 costs in money and effort
This table breaks the cost of meeting A.5.12 into its components, marking each as one-time or recurring and naming what pushes it up or down. Use it to scope a quote, since no fixed price applies across organizations and the largest swings usually come from system count, data type count and the quality of the existing inventory.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Software vendor or hosting team; self-hosted open source can remove license spend for the wiki, inventory and monitoring tools | Recurring for commercial licenses, one-time for setup of open-source hosting | Number of tools chosen, whether a wiki and inventory already exist, and whether hosting is in-house |
| Scheme design and owner approval | Management and information owners; an advisor may draft the scheme | One-time, with periodic review | Number of classification levels, number of business units and how many data owners must sign off |
| Engineering time for labelling and inventory integration | Internal platform or security engineers; implementation partner if scoped | One-time build, then recurring maintenance | Number of systems and repositories that need labels, and whether metadata tagging is automated |
| Inventory cleanup and asset ownership | Asset owners and IT operations staff | One-time cleanup, recurring upkeep | Quality of the existing asset inventory, age of records and rate of change in systems |
| Handling procedure and training | Security team writes; all staff who handle information take part | One-time to write, recurring to refresh | Number of data types, staff count and how often the scheme changes |
| Evidence upkeep | Compliance lead and control owners | Recurring, usually at each review cycle | Frequency of reclassification, number of systems in scope and how much evidence is captured automatically |
| External review or consultant support | Independent reviewers or an implementation partner, paid under a written scope | Usually one-time for readiness, sometimes recurring | Internal skills, scope size and whether reviews are needed before the certification audit |
| Auditor sampling time | Certification body auditors; the organization supplies people and records | Recurring at each audit cycle | How easily the organization can show labels matching the scheme and the inventory |
Which self-hosted open-source tools support classification evidence
XWiki is a wiki platform that can hold the classification policy, the level definitions and the handling rules for each level as pages. Its version history is the part auditors care about: each change is recorded with what changed, when and by whom, and earlier versions can be compared and restored. That gives you a dated trail showing when a classification level was added, reworded or retired, which matters when an assessor asks whether the scheme has been reviewed and approved.
- Versioned scheme pages: Each classification level, its criteria and its handling rules can sit on a page whose revision history records every edit.
- Change comparison: Reviewers can compare any two versions to see exactly how a handling rule changed between reviews.
- Rollback record: Restoring an earlier version leaves its own entry in the history, so an unauthorized edit is visible rather than silently overwritten.
- Linked handling guidance: Pages for labelling (A.5.13) and acceptable use (A.5.10) can link back to the scheme so readers see one authoritative version.
- License: XWiki is licensed under LGPL-2.1-or-later, so confirm with your legal team that this fits how you plan to use and modify it.
Confirm in your own environment that the version history retains the detail and retention period your audit requires, and that approval of each new version is recorded somewhere outside the wiki if your process needs it.
BookStack organizes documentation into shelves, books, chapters and pages, and controls who can see and edit each one through roles. For A.5.12, it can show that the classification scheme is published to the people who must apply it, while restricting edit rights to the owners who approve changes. Permissions can be overridden at the shelf, book, chapter or page level, which lets you keep a general scheme readable by staff while limiting an internal handling appendix to a smaller group.
- Role-based access: User abilities come from assigned roles, so the set of people who can read or edit the scheme is defined centrally.
- Granular overrides: Permissions can be changed per role at the shelf, book, chapter or page level, which suits a scheme with restricted annexes.
- Owner-controlled editing: Restricting edit rights to named policy owners supports the evidence that changes are authorized.
- Access evidence: Role assignments and permission settings can be exported or screenshotted as dated evidence, though you should confirm the export options in your version.
- License: BookStack is MIT licensed. Confirm the version you deploy and its permission model against the current documentation before relying on it.
Confirm that role assignments reflect your actual access review process and that restricted pages cannot be read through search or attachments by people outside the intended group.
GLPI's Assets module records computers, software, network equipment, peripherals and other items, and can hold the owner of each one. For A.5.12, the useful link is between a classified information asset and the systems that store or process it, with a named owner responsible for its level. Items can be entered manually or pushed automatically by the GLPI Agent through native inventory, which helps keep the record closer to reality than a spreadsheet kept by hand.
- Owner assignment: Recording a responsible user or group against each asset supports the requirement that classified information has an identified owner.
- Automated inventory: The GLPI Agent sends hardware and software data into GLPI, reducing manual entry for systems that hold classified data.
- Linking systems to levels: Using custom fields or categories to tag assets with their information classification is a configuration choice you must design and confirm in your installation.
- Reporting: Filtered lists of assets by owner or tag can serve as sampling evidence for an assessor.
- License: GLPI is GPL-3.0-or-later. Confirm the license obligations that apply if you modify and redistribute the software.
Confirm that GLPI holds the asset types you care about, that the agent covers the systems that process classified data, and that someone reviews the records on a set schedule.
The Wazuh Syscollector module gathers system inventory from each endpoint, including hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates. Stored in the Wazuh indexer, this data appears in dashboard inventory views and reports. For A.5.12, it does not classify anything, but it lets you check that the systems you have labelled as holding confidential or restricted information are actually present, configured as recorded and running the expected services.
- Endpoint inventory: Syscollector reports hardware, software and services per host, which can be matched against the asset list for classified systems.
- Network exposure: Open ports and network interfaces show whether a system holding restricted data is reachable in ways its classification does not justify.
- User and group views: Local users and groups support checks on who can reach systems that hold classified information.
- Reporting: Dashboard reports can be exported as dated evidence of the inventory at a point in time.
- License: Wazuh is GPL-2.0-only. Confirm the license terms for the components and integrations in your deployment.
Confirm that Syscollector runs on every host in scope in your environment, that collection frequency meets your needs, and that its data is reconciled with the GLPI asset record rather than trusted alone.
Where classification programs usually fall short
Most classification schemes fail in operation rather than on paper. The gaps below share a root cause: the scheme exists as a document, but nobody owns it, applies it consistently, or checks it against the systems where information actually sits.
Too many classification levels
A scheme with six or seven levels looks thorough, but staff cannot tell the levels apart, so they default to the middle one or to none. A.5.12 expects levels that reflect real security needs in terms of confidentiality, integrity and availability. Check whether each level has a distinct handling rule that someone can state from memory. If two levels produce the same controls, merge them.
Criteria that depend on opinion
When the test for a level is whether the document 'feels sensitive', two employees will classify the same file differently. Auditors sampling records will find inconsistent results and will ask how the decision was made. Write criteria as concrete questions, such as whether disclosure would breach a contract or personal data rule, and record the answers that led to each level.
No named owners
Classification is only applied when someone is accountable for deciding the level of an information asset. Without a named information owner for each system or repository, reclassification requests stall and old labels persist. Confirm that each owner is recorded, knows the decision is theirs, and reviews the level when the use of the information changes.
Labels not applied in tools
A policy that requires markings on documents, email and file shares is often ignored because the tools never enforce it. The label may exist only in a template that people forget to use. Check a sample of working files in the collaboration and storage platforms you actually run, and confirm that markings appear in document metadata and exported copies, as the labelling control A.5.13 requires.
Scheme not linked to the asset inventory
A classification that is not recorded against each asset in the inventory cannot be enforced or evidenced. Auditors often pick an asset from the inventory and ask for its level and owner. If the answer is missing, the scheme is decorative. Confirm that every asset record in A.5.9 carries a classification field, and that a report can list all assets at each level.
No review after organizational change
Mergers, new products, new cloud regions and new customer contracts all change what information is sensitive. A scheme written once and never reviewed will misclassify new data. Set a review trigger tied to organizational change as well as a routine interval, and check that the last review date and its outcome are recorded in the policy history.
Questions buyers and practitioners ask about A.5.12
How much effort does an information classification scheme take for a small team?
The effort depends mostly on how much information the organization holds and how many systems store it, not on the number of people. A scheme with three or four levels, written in plain language, is usually enough for a small team, and most of the work is in agreeing the criteria and then labelling the places where information lives. The main recurring effort is keeping the inventory current, because new tools and data stores quietly create unclassified information. Ask for the number of systems and data repositories in scope before accepting any estimate, since that count drives the work far more than headcount.
Can we write an information classification scheme without hiring a consultant?
Yes, an organization can write its own scheme, and A.5.12 does not require outside help. The standard asks for classification based on the organization's own security needs and the requirements of interested parties, so the people who understand the data must make the judgments. External help is most useful for checking that the scheme is consistent with the rest of the ISMS and for reviewing it before an assessor sees it. If you do bring in a partner, ask who owns the final decisions, because the organization must own its controls and the partner only prepares the systems and evidence.
What does a classification scheme need from management and information owners?
It needs a decision from management on the levels and the criteria, and named owners who decide the classification of each information set. Management must approve the scheme, fund the labelling and inventory work, and enforce handling rules when people disagree. Owners, usually business or system leads, must be able to say what harm a leak, alteration or outage would cause, because that is the basis for choosing a level. Record these responsibilities in writing, since an auditor will ask who assigned each level and whether the assignment was reviewed.
How long does it take to set up classification under A.5.12?
The duration depends on scope: the number of information types, systems, suppliers and sites that the scheme must cover, plus how many owners need to be consulted. The written scope agreed before work starts sets the timeline, so ask for a dated plan that lists the systems in scope, the owners who must sign off, and the review points. Any timeline given without a defined scope should be treated as a guess.
Does a classification scheme need to cover AI systems and cloud data?
Yes, if the organization stores or processes information in those environments, the scheme should cover it. Training data, prompts, model outputs, embeddings and logs can all carry confidential or personal information, and cloud storage often replicates data across regions and services. A.5.12 applies to information in any form, so the classification must follow the data into these places and into the handling rules that govern them. Check that the cloud and AI tools in use can apply the labels or at least carry the classification in their metadata, and document the gaps where they cannot.
What will an auditor sample when checking A.5.12?
An auditor usually picks several information sets and asks to see their classification, the criteria used, who assigned the level and the handling rules that apply to that level. They then compare those records with the inventory and with real storage locations to test whether the classification was applied in practice, not only written down. Expect requests for the approved scheme, owner decisions, labelled samples from file shares or repositories, and evidence that unlabelled or misclassified information was corrected. Keep the change history of the scheme and the inventory, because gaps between the document and the systems are the most common finding.
Which open-source tools help keep classified information under control?
Tools can hold the classification records and show where information lives, but they do not decide the level. A wiki with version control, such as XWiki, can hold the approved scheme and show its change history, and BookStack can hold handling procedures with role-based permissions. GLPI can record assets and their owners, and Wazuh can inventory endpoint software and configuration so you can check whether assets exist where the inventory says they do. Confirm each tool's capabilities against your own environment before relying on it for evidence.
How DeployOpen prepares classification evidence in your environment
DeployOpen works on A.5.12 as a fixed-scope engagement inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. The written scope names the systems that hold information, the classification levels already in use or agreed for the work, and the platforms where labels and handling rules must be visible. Before any build starts, the organization decides its scheme, the levels, the criteria for each level and who may assign or change a level. The organization owns those decisions. DeployOpen does not set your confidentiality, integrity or availability thresholds, and it does not decide what a customer or regulator requires.
Once the scheme is settled, DeployOpen configures the self-hosted platforms that hold the evidence. In practice this can include recording owners and classification fields against assets in GLPI, keeping the scheme and handling rules in version-controlled XWiki or BookStack pages with role-based access, and using Wazuh system inventory to show which endpoints and software exist so that classified information can be traced to real systems. Each configuration is documented, and the records are exported in a form your assessor can sample. Confirm with the platform vendors which fields and permissions your chosen versions support before you commit to a design.
DeployOpen does not issue audit reports, attestations or certificates. Only an independent auditor or certification body can assess whether A.5.12 is met and whether the ISMS as a whole is certified. Ask your certification body early which records it will sample, how far back it expects them to go and whether it accepts the self-hosted tools you plan to use. The output of the engagement is a set of prepared systems, procedures and evidence that you present to that assessor, and the classification decisions remain yours to defend.
