What A.5.13 labelling of information asks your organization to do
When an auditor or a customer questionnaire asks how your information is marked, the short answer is that Annex A control A.5.13 requires you to develop and implement an appropriate set of procedures for labelling information, and those procedures must follow the information classification scheme your organization has adopted. The control does not invent new categories. It asks you to show that the levels you defined under A.5.12 Classification of information are visibly applied to the information itself, so that a person or tool can see how a document, record or file must be handled. The risk it addresses is familiar: a confidential contract is emailed to the wrong recipient, a restricted dataset is copied to a shared drive, or a printed board paper is left on a desk because nothing on it signalled its sensitivity. ISO/IEC 27001:2022 carries this forward from control A.8.2.2 Labelling of information in the 2013 edition, so organizations that already had labelling in place will recognize the intent, though the 2022 wording is organized differently.
The difficulty is coverage. Labels must work across very different carriers: Word and PDF documents, database fields and report headers, email subjects and footers, file and folder metadata, collaboration platform tags, and physical media such as printed pages, USB drives and backup tapes. Each carrier has its own mechanism, and a label that exists in one place but not in another is usually where the incident happens. Before writing procedures, confirm with your team which carriers hold information at each classification level, who is responsible for applying labels on each, and whether any labels are applied automatically by tools or only by hand. ISO/IEC 27002:2022 gives implementation guidance on this control, and that guidance is the natural reference for the people who write the procedures. Use it to shape your own rules rather than copying text into your policy set.
Which systems, media and teams fall under labelling scope
Labelling scope is set by where classified information lives and moves, not by the policy text alone. The cards below cover the places where labels are most often missed, and each one links back to the classification levels from A.5.12 that determine how many label types the organization needs.
Document types and templates
Word processing files, spreadsheets, slide decks, PDFs and email attachments are the most common labelled objects. Labels should appear in the document itself and in the template library, so new files start with the right marking. Check that each template carries the label field, that legacy templates are retired, and that a sample of recent files from each team shows the expected marking.
Collaboration and wiki platforms
Shared workspaces, wikis and document management systems often hold the most sensitive working drafts. Confirm which platform features can display a label on a page or file, whether labels follow content when it is copied or moved, and whether version history keeps earlier labels visible. Self-hosted platforms differ in how far they can enforce labels, so test this in your own environment before writing it into procedure.
Databases, exports and reports
Labels usually stop at the application screen. Query results, CSV exports, dashboards and scheduled reports can carry customer or personal data with no marking at all. Decide where the label is recorded (a column, a file header, a report title), who owns each export path, and how a reader of a downloaded file can tell its classification without opening the source system.
Metadata fields and tags
Metadata is where labels become machine-readable, which is what allows access rules, data loss prevention and search filters to act on them. Define a fixed set of metadata keys and allowed values, then document who may change them. Free-text tags drift quickly, so an auditor will expect a controlled vocabulary that matches the classification scheme.
Printed and removable media
Printed pages, USB drives, backup tapes, optical discs and removable disks leave the systems that enforce labels. Each physical item needs a visible marking and a handling rule that matches its level. Confirm who prints restricted material, how printouts are marked and collected, and how media are labelled before they leave a controlled area or are sent for disposal.
Third parties receiving labelled information
Suppliers, auditors, consultants and partners receive labelled files and must understand what the labels mean. Include label definitions and handling expectations in supplier agreements, and confirm that labels survive when files are sent through transfer tools. Ask each recipient group which labels they will see, and whether they can apply the same labels to material they return.
How an assessor tests labelling of information
This table sets out each step an assessor takes to test A.5.13, what they ask for, and where labelling programs usually fail. Read it as a checklist: a labelling procedure only counts if it matches the classification scheme in A.5.12, appears on real records and exports, and drives the handling rules people follow.
| Test step | What the assessor checks | Evidence usually requested |
|---|---|---|
| Confirm the procedure exists | A documented labelling procedure exists, is approved, and is built on the classification levels defined under A.5.12 | Labelling procedure, classification scheme, approval record and version history |
| Match scheme to procedure | Every classification level has a defined label, and label names in the procedure match the scheme word for word | Side-by-side comparison of the scheme and the labelling procedure |
| Sample labelled records | A sample of documents, spreadsheets, tickets and repository items carries the correct label for its level | Sample list from the inventory under A.5.9, with the label shown on each item |
| Check systems and metadata | Labels stored as metadata or system tags are set by default or enforced, not left to user choice where the risk is high | Configuration screenshots, default templates, tag or metadata settings |
| Check labels at creation and export | Labels follow the information when it is copied, exported, printed or sent out of the system | Export samples in PDF, CSV and email, plus print and media labelling examples |
| Check physical media | Removable media, printouts and shipped media carry visible labels that match their classification | Media register, physical labelling samples, shipping or courier records |
| Test handling rules | The handling rules tied to each label are followed, such as sharing limits, encryption or storage locations | Access logs, sharing settings, transfer records under A.5.14 and sample exceptions |
| Review common findings | Unlabelled exports, inconsistent label names such as Confidential and CONF, and procedures that describe practice nobody follows | Nonconformity records, corrective actions and retest results |
How to implement labelling in the order an audit expects
This sequence builds labelling from the classification scheme outward, so each label traces back to a documented decision and an auditor can follow the chain from policy to the label a user sees on a file, a record or a disk.
Confirm the classification scheme first
Start from the classification scheme under A.5.12, because labels only mean something when they map to approved levels. Confirm the levels, their definitions, who assigns them and how they drive handling, and get the scheme approved by the owner of information security. The output is a signed scheme document that the labelling procedure cites by version. If the scheme is still in draft, stop here, since every later step depends on it.
Define label values and where each appears
Translate each classification level into a label value, then decide where that value must appear: document headers and footers, file names or metadata, email subject lines, system fields, database columns, tickets and physical media. Record the decisions in an approved label matrix that lists each level, its exact marking text, each location and the owner of that location. Auditors often sample this matrix against real files, so unclear entries cause findings later.
Write the labelling procedure
Write the procedure that tells people and system owners how to apply, check and correct labels. It should cover manual labelling, inherited labels when content is copied or combined, handling of unlabelled legacy content, and what to do when a label is missing or wrong. Cite the matrix as the source of truth. The procedure is complete when the owner of information security approves it, it is published where staff can find it, and each reviewer has a recorded acknowledgement.
Configure tools to apply or enforce labels
Configure the systems that hold information so labels are applied by default or enforced where the matrix requires it. Open-source platforms can carry labels in several ways, for example through access rules that block sharing or download based on tags or file attributes, through page or space templates that carry a marking, or through metadata fields that workflows check. Keep a tool configuration record for each system showing the setting, the label values it uses and the test that proves it works. Confirm each capability in the vendor documentation for the version you run.
Train staff on applying labels
Train the people who create, receive and share information on the matrix, the procedure and the tools they will use. Use short, role-specific sessions for document authors, system administrators and anyone who handles physical media. Keep attendance and the training material as evidence. Training is complete when each role group has been trained and the records name the people who attended, with dates taken from your own calendar and LMS rather than from any external source.
Label physical media and output
Apply the matrix to physical media such as removable drives, backup tapes, printed reports and shipped hardware. Labels should be readable without opening the medium, and they should match the electronic classification so that handling rules follow the content. Record the labelling method for each media type in the procedure, and keep a log for media that leaves the building. Sample a set of media against the log to confirm the labels match the records.
Review labels and close the loop
Review labelling at planned intervals and after significant changes to the scheme or the tools. Sample documents, system fields and physical media, compare them with the matrix, and log each mismatch with a corrective action and an owner. Feed recurring errors back into the procedure, training or tool configuration. The review is closed when findings have owners, the matrix and procedure are updated under version control, and the next review date is recorded.
Where labels live: documents, systems, metadata and physical media
Documents and wiki pages are where most labels are written by hand, so the label is usually a header, footer, title prefix or page property that the author sets from the classification scheme. The risk is drift: a page is copied, exported or edited and the label is lost or left at an older level. Labelling here works best when templates carry the label by default and the platform keeps a record of who changed what.
- Templates: Standard document templates carry the classification label in the header or footer so new content starts labelled.
- Wiki page properties: Wiki platforms can store the classification as a page property or tag, which lets pages be listed and reviewed by label.
- Version history: Version control shows who changed a label and when, which is the record an auditor samples.
- Exports and copies: Check that PDF exports and copied sections keep the label, since these leave the original page.
- Review rights: Restrict who can change a label and who can publish content at the highest level.
Check a sample of documents at each classification level against the scheme and confirm the label matches the approved level in the version history.
File storage and sharing platforms can make labels actionable. A label that only appears in a filename does nothing on its own, but a label tied to a rule can restrict upload, download, sharing or sync. This is where labelling connects to handling controls and to A.5.14 Information transfer. Ask whether your platform can read a label, tag or attribute and apply policy to it, or whether labels will rely on users.
- Tag-based rules: Nextcloud's File Access Control app can deny upload, modification, deletion, download and sync when rules match on collaborative tags, so a classification tag can drive restrictions.
- Group and network conditions: Rules can also match on user group, IP address, file name, MIME type or user agent to limit where labelled content may go.
- Naming conventions: Filenames can carry a level, but treat this as a visual cue only and pair it with a tag or rule.
- Admin configuration: Keep the rule set, its change history and the tags it depends on under configuration control.
- Test cases: Record tests showing that a labelled file is blocked from a restricted path or action.
Confirm the exact tag and rule behavior in the current administrator documentation for your version before relying on it as evidence.
Structured systems such as databases, ticketing tools, asset registers and document management systems often hold labels as fields rather than visible marks. A classification field is only useful if it is mandatory, constrained to the approved values and consistent with the inventory. Metadata labels are also how tools decide what to log, encrypt or export, so they must be accurate at the data level and not only in a policy.
- Controlled values: Use a fixed list of classification values so free text such as 'internal-ish' cannot enter the record.
- Mandatory fields: Make the classification field required at creation and at import.
- Inheritance: Define whether a derived dataset, report or export inherits the highest level of its sources.
- Role-based editing: Permissions to set or lower a classification should sit with the named owner, which can be shown through the access model in the wiki or identity system.
- Reconciliation: Compare the field values with the information inventory on a set schedule and record exceptions.
Ask the system owner to show the field definition, a sample of records and the change log for the classification field.
Physical media, including printed documents, USB drives, backup tapes, laptops and removable disks, need a label that a person can read without a system. The label must survive handling and must be linked to a register so that a lost or reissued item can be traced. This area overlaps with the physical and media controls, so coordinate with those owners rather than duplicating them.
- Visible marking: Apply the classification to the outside of the media and to printed pages, including cover sheets for printed sets.
- Media register: Record each removable device or tape with its label, owner and location, and update it on issue and return.
- Storage handling: Store labelled media in areas matched to the highest level they hold.
- Disposal records: Keep records showing that labelled media was wiped or destroyed according to its level.
- Printing controls: Where printing is allowed, confirm that labelled content prints with its marking.
Sample a few labelled items against the register and confirm each one can be traced to an owner and a current location.
Labels are only as good as the checks behind them. Each environment needs a named checker, a routine and a record, and the records should be the same ones an auditor will sample. Plan these checks before the audit so the evidence exists when the auditor asks for it. An independent auditor tests the design and sampling results, while your team owns the checks.
- Owners: Name the information owner who sets the level and the custodian who maintains the mechanism in each environment.
- Sampling routine: Set a routine where someone checks a sample of labels in each environment and records exceptions.
- Exception handling: Track mislabelled items to correction and to root cause, linking to A.5.36 compliance reviews.
- Evidence set: Keep templates, rule configurations, field definitions, change logs, register extracts and sampling records together.
- Training: Keep records that people who apply labels know the scheme and the handling for each level.
Ask your auditor which environments they expect to sample and confirm that each has a record the owner can produce on request.
Evidence that passes A.5.13 and how to keep it current
An auditor testing A.5.13 looks for a labelling procedure that matches the classification scheme, and then checks that labels actually appear on real information. The cards below cover the artifacts that prove both points and the routine that keeps them accurate between audits.
Approved labelling procedure
The written procedure sets out which label goes on which class of information, who applies it, where it sits on documents, systems, metadata and physical media, and what happens when a label is missing or wrong. Auditors check that it names an owner, carries an approval date and cross-references the classification scheme under A.5.12. Confirm that the version in circulation is the approved one, not a draft saved in a shared folder.
Label matrix tied to classification
A label matrix maps each classification level to its visible marking, metadata tags, file naming pattern and handling rule. It is the artifact that proves the labelling procedure follows the classification scheme in use, so a reviewer can trace one level from policy to a labelled file. Check that every level in the scheme appears in the matrix and that no label exists without a classification behind it.
Tool configuration exports
Where systems apply labels automatically, such as document platforms, file sync services or wiki spaces, export the relevant configuration and keep it with the change record. For example, an illustrative file access rule that blocks download of files tagged at the highest level should be shown with its date and the approver. Confirm that the export matches what runs in production, since a configuration that was tested but never deployed is weak evidence.
Labelled samples and version history
Auditors sample real documents and records and check that each carries the label its classification requires. Version history matters here because it shows when a label was added, changed or removed and by whom. Pull a sample across several classification levels and departments before each audit, and record any mismatch along with its correction.
Training records and acknowledgements
Staff who create or handle information need to know the labels and their meaning. Keep attendance records, quiz results or signed acknowledgements of the labelling procedure, linked to the people in the identity system so that joiners and movers can be traced. Check that new hires and role changes trigger a training requirement rather than relying on an annual refresh alone.
Exception log and refresh routine
Record every exception, such as an unlabelled legacy archive or a system that cannot display a marking, with a named owner, a compensating control and a review date. Refresh the whole evidence set on a fixed schedule between audits, comparing the matrix, configurations and samples against the current classification scheme. A snapshot taken once before audit day will not show drift, so ask the team to show the last refresh and what it changed.
What meeting A.5.13 costs in money and effort
This table breaks the cost of A.5.13 labelling into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No supplied figures exist for these costs, so use the drivers to frame your own estimate and the questions to put to any quote. Self-hosted open source mainly removes license spend, not configuration and upkeep effort.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling or licenses | Software vendor, or none if self-hosted open source is used | Recurring if commercial, often one-time setup otherwise | Number of users, labelling products chosen, and whether labels must integrate with existing document or email tools |
| Engineering time to configure labels | Internal platform engineers or an implementation partner under a written scope | One-time, with later changes | Number of systems that carry labels, metadata schemas, and whether tools enforce handling rules or only display labels |
| Staff time to write labelling procedures | Information security or compliance staff, with input from information owners | One-time, then periodic review | Number of classification levels, media types covered, and how many exceptions the procedure must describe |
| Training and communication | Internal trainers or the training provider, plus staff time in sessions | Recurring for new joiners and periodic refreshers | Headcount, turnover, and how many roles create or handle labelled information |
| Evidence upkeep | Control owners who keep samples, label records and configuration exports current | Recurring | Frequency of label-driven changes, number of repositories, and how often ownership changes |
| Internal reviews | Control owners and management reviewers | Recurring, at a planned interval | Scope of the ISMS, number of sites and systems, and findings from earlier reviews |
| Auditor sampling | Certification body, with staff preparing the samples | Recurring with each audit cycle | Sample size the auditor selects, how many systems hold labelled data, and whether labels are consistent across them |
| Remediation of gaps | Internal teams or the implementation partner | One-time per finding, plus any recurrence | Unlabelled repositories, inconsistent labels between tools, and missing records for media handling |
Your team, an implementation partner and the auditor
The organization owns the decisions that make labelling meaningful. Under A.5.13, the procedures must follow the information classification scheme the organization has adopted under A.5.12, so the people who own that scheme and the information it covers must decide what each level means, which label applies to which information, and who may change a label. Information owners, the security function and business leads typically share this work, and management approval of the scheme and its procedures is part of the evidence an assessor will ask for.
- Classification scheme: Set the levels, their definitions and the handling rules each level requires.
- Label decisions: Assign owners who decide the label for documents, systems and datasets that do not fall under a default rule.
- Exceptions and downgrades: Approve any change to a label and record who made it and why.
- Approval and communication: Approve the labelling procedure and brief staff on it.
- Ongoing ownership: Review labels when information changes sensitivity, such as after a project or contract ends.
Check that each decision has a named owner and a recorded approval, because an auditor will sample those records.
An implementation partner prepares the systems and documents that carry the organization's decisions into daily work. For labelling, that usually means configuring the self-hosted platforms so that labels are visible and enforced, drafting the labelling procedure for the organization to approve, and collecting the evidence that shows the procedure operates. The partner does not decide the classification levels or sign off on labels, and it does not judge whether the control is effective.
- Tool configuration: Set up label fields, metadata and access rules in the document and file platforms the organization runs.
- Procedure drafts: Write the labelling procedure from the organization's scheme, for the organization to review and approve.
- Evidence collection: Export configuration, version histories and sample label records on a defined schedule.
- Training material: Prepare short guidance for staff, delivered under the organization's own awareness programme.
- Gap reporting: Report where labels are missing or inconsistent so the organization can decide on fixes.
Ask any partner to state in writing which deliverables it prepares and which decisions remain with your staff.
Only an independent auditor or a certification body can test the control and issue a certificate. The auditor samples labelled information, compares labels with the classification scheme, and checks that the procedure is followed in practice. A certification body is accredited to certify ISO/IEC 27001 and must work under ISO/IEC 17021-1 and ISO/IEC 27006-1, which require separation between the people who advise and the people who certify. An organization that receives consulting from a body that also certifies it may face independence concerns, so the two roles should be kept apart.
- Sampling: The auditor selects documents, systems and media and checks their labels against the scheme.
- Testing the procedure: The auditor asks staff how they label information and compares their answers with the written procedure.
- Findings: Gaps are raised as nonconformities or observations, which the organization must address.
- Certification decision: Only the certification body decides whether the organization meets the standard.
- Accreditation check: Confirm the body is accredited before you rely on its certificate.
Confirm the certification body's accreditation and its independence policy before engaging any consultant.
Most organizations outsource the technical and documentation work for labelling, but keep the classification decisions in-house. Outsourcing usually covers configuring platforms, drafting procedures, preparing evidence and running awareness sessions. The organization still needs to own the approvals, the label decisions and the review cycle, since these are what the auditor tests as evidence of management control.
- Usually outsourced: Platform configuration, procedure drafting, evidence export and training material.
- Usually kept in-house: Classification levels, label approvals, exception decisions and staff accountability.
- Shared work: Testing that labels appear correctly in day-to-day tools.
- Costs to expect: Implementation work is typically a fixed-scope engagement, and a separate fee applies to the certification audit itself.
- Cost drivers: The number of systems, the number of classification levels and the volume of existing unlabelled information.
Ask each provider for a written scope that lists the deliverables and the decisions that remain with your organization.
Where labelling programs usually fall short
Most labelling programs fail between the policy and daily work, not in the classification scheme itself. The gaps below share one root cause: a label exists on paper but nobody, or no tool, applies it at the point where information moves, is printed or is handled. Each card names a gap, why an assessor cares, and how to close it.
Labels never reach exports and attachments
The scheme defines markings for documents, but exported reports, CSV extracts and email attachments leave the system unlabelled. An assessor will often pick an export from a business system and ask for its marking. Check each system that produces files, confirm whether it can stamp a classification into headers, footers or file metadata, and where it cannot, document a manual step and test a sample of exports against the scheme.
No marking for physical media and printouts
Labelling programs often stop at digital files, leaving printed pages, USB drives, backup tapes and laptops without a visible marking. The control covers physical media as well as documents, so printouts and removable media need the same classification that governs their electronic copies. Confirm which print paths and media types exist, set a marking standard for each, and check that cover sheets or media labels are in place at the points of use.
Labels that do not drive handling rules
A label such as Confidential has value only when each level maps to a specific rule on storage, sharing, encryption and disposal. Many schemes name levels but never say what changes for a person holding the file. Write a short handling matrix that links each label to permitted locations, sharing scope and transfer methods, and confirm that tools enforce or at least reflect those rules. Auditors test this link when they trace a label to its handling.
Procedures describe a tool nobody uses
A labelling procedure may name a document management system, a plug-in or a template that staff have stopped using or never adopted. When the written method and the working method differ, the procedure fails the test of being implemented. Walk through the procedure with a few real users, record how labels are actually applied, and either update the procedure or change the tool configuration so the two agree. Keep the revised version under document control.
Version history of label changes missing
When a classification changes, for example a document is downgraded after a project closes, the change needs a traceable record. Without version history, an assessor cannot confirm who changed a label, when, and on what authority. Confirm that the platform keeps prior versions and records the author and date of each change, and set a rule that reclassification requires an owner's approval, recorded in the same place as the document.
No evidence that staff were trained
A labelling scheme that staff have never been shown produces inconsistent markings, and assessors commonly ask how people learned the rules. Training records, acknowledgements of the handling rules and short spot checks of recently created files show that the procedure reached the people who apply it. Plan a short training module, keep attendance and acknowledgement records, and repeat the module when the scheme changes or new staff join.
Questions buyers ask about A.5.13 cost, effort and outside help
How long does it take to implement labelling of information?
The duration depends on how many systems, document repositories and physical media types must carry labels, and on whether the classification scheme under A.5.12 is already settled. No researched duration applies to every organization, so treat any timeline as a planning estimate to confirm in writing. The work usually runs in stages: agree the label set and the handling rule for each level, define where labels appear, configure the tools that apply them, then train staff and sample results. A scope that covers two or three repositories is far shorter to finish than one that covers email, file shares, collaboration tools, backups and printed output. Ask any implementation partner to break the timeline into these stages in the written scope before work starts.
Can a small team implement A.5.13 in-house?
Yes, a small team can usually write the labelling procedure and apply it to a limited set of systems without outside help, provided someone owns the classification scheme and has time to check results. The control asks for a set of procedures that follows the organization's classification scheme, so the first step is a short, clear label list tied to handling rules. The harder part is technical enforcement: a label that only exists in a policy document does not stop a file being shared externally. Small teams often choose self-hosted tools that support labels, access rules or version history, and then need someone who can configure them. Outside help is most useful for that configuration step, not for writing the policy.
What does the labelling work need from staff?
Staff need to know which label applies to the information they create, what each label means for sharing and storage, and what to do when unsure. In practice this means a short briefing, a one-page reference of labels with examples, and a visible label on the document, message or file itself. Staff who create information are the ones who apply most labels, so their workload should be measured during rollout. Plan for a review period after go-live, when managers check a sample of documents and correct recurring mistakes. Auditors often ask staff directly what a label means, so the answers should match the procedure.
What drives the cost of A.5.13 up or down?
Cost depends mainly on the number of systems that must show labels, the depth of technical enforcement, and the amount of existing information that needs relabelling. Costs fall into one-time items (designing the label scheme, configuring tools, writing procedures, training) and recurring items (periodic review, staff refresher training, maintaining tool configuration and sampling). Using tools the organization already runs usually costs less than adding new platforms. Ask any quote to list who performs each task, which systems are in scope, what is included in training, and what happens to existing content. No researched cost figure applies to this control, so compare quotes on the written scope rather than on headline totals.
Can an implementation partner configure labelling tools for us?
A partner can configure labelling and access rules in tools the organization hosts, such as file access controls, version history and page permissions, provided the scope names the tools and the target configuration. DeployOpen plans, implements, customizes and documents self-hosted open-source platforms inside the client's own infrastructure, so configuration work of this kind falls within that scope. The organization still owns the classification scheme and the decision on which label applies to which information. Confirm with the partner which configuration changes they will make, how they will test them, and how the settings will be documented as evidence.
What will an auditor sample for A.5.13?
An auditor will usually ask for the labelling procedure, the classification scheme it follows, and evidence that labels are applied in practice. Typical samples include documents from several repositories, labelled outputs from the tools in scope, and records of staff training or communication about labels. The auditor will also check whether handling rules for each label match the procedure, and whether physical media and printed material are covered where the scope requires it. Ask the auditor early which systems they consider in scope and what sample sizes they expect, because these vary by certification body and by the scope of the ISMS. An independent auditor or certification body issues any finding or certificate; DeployOpen prepares systems and evidence but does not issue audit reports.
How does labelling connect to the classification scheme and transfers?
Labelling only works when the classification scheme under A.5.12 is clear, because each label must map to a level with a defined handling rule. Labels also matter for information transfer under A.5.14, since a transfer rule can depend on the label of the file being sent. Confirm during scoping that the label set, the handling rules and the transfer rules agree with each other, so an auditor does not find two procedures that contradict each other. Related controls such as A.5.10 on acceptable use also draw on the same labels.
How DeployOpen scopes and prepares labelling evidence
DeployOpen scopes labelling work for A.5.13 as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before any configuration begins. The first decisions are practical: which classification levels from the organization's own A.5.12 scheme must be visible on each kind of object, which repositories and platforms carry labelled information, and which label formats must appear on documents, in metadata, in file names and on physical media such as printed reports or removable drives. The organization owns the classification scheme and the labelling procedure. DeployOpen's role is to prepare the systems, configuration and records that let people and tools apply that procedure consistently inside the client's own cloud accounts, data centers or air-gapped networks. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies assess the controls and decide whether they meet the standard.
On self-hosted platforms, the labelling evidence usually comes from configuration that enforces the scheme rather than from policy text alone. In a file platform such as Nextcloud, the File Access Control app can be set to deny upload, download, sharing or sync for files that match rules on collaborative tags, file name or MIME type, so a label applied as a tag can drive handling. In a wiki such as XWiki, page version history records what changed, when and by whom, which gives an assessor a trail showing that a label was applied and later revised. In BookStack, permissions can be overridden per shelf, book, chapter or page, so the label on a container can match who may read it. Each of these needs to be confirmed against the exact version the client runs, and the tag, rule and permission names must be agreed with the classification owner before configuration starts.
Before buying outside help, the organization should ask an implementation partner for a written list of what will be configured, what will remain manual, and which records will be exported as evidence. Expect the manual part to include the labelling procedure itself, staff guidance on labelling physical media and email, and the periodic checks that compare labels against real content, since no tool confirms that a person labelled a printed document correctly. Ask how the evidence will be retained and who will sign off the configuration. A quote should follow from that written scope, and the organization should confirm the exact deliverables with its own auditor so that the evidence is packaged in the form the assessment expects.
