Why an ISO 27001 data catalog starts with a named inventory of datasets
A security or data governance lead preparing for an ISO 27001 assessment has to answer three questions for an auditor: which datasets exist, who owns each one and how each one is classified. An open source catalog can hold those answers, but only once every dataset has a named owner, a classification and a label recorded in it, and someone is responsible for keeping those entries current. The catalog is the working record. It is not, by itself, evidence of compliance.
Annex A control A.5.9 asks the organization to build and maintain an inventory of its information and associated assets, with owners recorded, so that those assets can be identified and protected. A.5.12 asks for information to be classified according to its confidentiality, integrity and availability needs and the requirements of interested parties. A.5.13 asks for labelling procedures that follow the classification scheme the organization has adopted. In practice, the catalog holds the inventory (A.5.9), a classification tag on each dataset (A.5.12), and the label that travels with the data (A.5.13). The implementation guidance for these controls sits in ISO/IEC 27002:2022, which the reader should obtain directly from ISO.
ISO does not certify organizations. Accredited certification bodies do that work after an audit, and DeployOpen prepares the systems, controls and evidence those auditors will examine but does not issue audit reports or certifications. Before scoping the work, confirm with the certification body which evidence it expects for A.5.9 to A.5.13 and whether it will sample catalog entries. A named inventory with owners and classifications is a stronger starting point than a spreadsheet exported once a year.
How A.5.9, A.5.12 and A.5.13 map to catalog functions
This table maps each ISO/IEC 27001:2022 control in scope to what the catalog must do and how to configure it in OpenMetadata or DataHub. Read each row as a requirement, the catalog configuration that supports it and the evidence an assessor is likely to ask to see. The main takeaway is that the controls are only as strong as the ownership and review habits behind the tags.
| Control | What the catalog must do | How to configure it in OpenMetadata or DataHub |
|---|---|---|
| A.5.9 Inventory and owners | Hold a current register of datasets, databases, dashboards and pipelines, each with a named owner | Ingest sources with connectors, then set owner fields on databases, schemas and tables; use domains to group assets by business area |
| A.5.12 Classification | Assign each asset a classification level based on confidentiality, integrity and availability needs | Define a classification tag set (for example, public, internal, confidential, restricted) and apply it at table or column level with a description of each level |
| A.5.13 Labelling | Apply labels that follow the adopted classification scheme and a documented labelling procedure | Link each classification tag to a glossary term or policy text, and make the procedure the reference for how tags are assigned and displayed |
| Personal data flags | Show which classified assets hold personal data so the scheme can be applied consistently | Use a sensitive or PII classification tag with a documented rule for when it applies, then review auto-classification results before they are accepted |
| Ownership accountability | Show who approved each classification and who is accountable for changes | Record the steward or owner on each asset and keep the approval trail in the catalog's change history or ticket references |
| Lineage for inventory completeness | Show where derived datasets come from so downstream assets are not missed in the inventory | Enable table and column lineage from supported pipelines and check that derived assets inherit or receive classification and owners |
| Review cycle | Keep the inventory, owners and labels current as systems change | Run scheduled ingestion, flag assets with no owner or tag, and set a review cadence set by the organization's own policy, with owners confirming their assets each cycle |
| Access and labelling in downstream tools | Carry labels to places where data is consumed, such as dashboards and exports | Confirm with the vendor which downstream tools display or enforce tags before relying on them as a control |
Which open source catalog fits an ISO 27001 inventory
An A.5.9 inventory needs a place to record assets, owners and classifications, and the catalog choice depends on whether that inventory stays internal or becomes a published data portal. The cards below compare the options and the search, dependency and hosting needs that should drive the decision.
OpenMetadata for the internal inventory
OpenMetadata is released under Apache-2.0 and covers the internal inventory well: more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, table, column, dashboard, pipeline and metric lineage, classifications, glossaries and domains. Owners can be attached per dataset, and the REST APIs and Python SDK let you load asset records from systems the connectors do not cover. Check that your sources have supported connectors and plan the work for any custom ones.
DataHub as the alternative internal catalog
DataHub is also Apache-2.0 licensed and is a strong candidate when the inventory needs to sit alongside a large existing metadata graph. The current release supplied for this topic is v1.7.0.1. Compare the two platforms on the connectors your estate actually uses, how ownership and glossary terms are maintained, the operational footprint of each, and how your team would handle upgrades.
CKAN for a published portal
CKAN is an open-source data management system for data hubs and portals, licensed under AGPL v3.0. It fits when the goal is to publish datasets to citizens, partners or the public rather than to run an internal inventory of every asset. The DataStore keeps structured resource data in PostgreSQL with a read-only user for the Data API, and the ckanext-dcat extension provides DCAT-AP schemas for interoperable publication. Confirm the AGPL obligations with your legal team before exposing modified code.
Search and dependency needs
Pick the catalog by the questions it must answer. If auditors will ask which systems hold a given asset and who owns it, you need strong search, column-level lineage and dependency mapping from pipelines. If the portal only lists approved datasets with DCAT metadata, a data portal model is enough. Write these requirements down, test them against two or three candidates using a sample of your own sources, and record the results as evidence for the decision.
Hosting in your own infrastructure
Deploy the catalog in your own cloud accounts, data centers or air-gapped network, because the inventory itself lists sensitive systems, owners and classifications. OpenMetadata documents Kubernetes deployments on EKS, AKS, GKE and on-premises clusters, and bare metal with Java 21, PostgreSQL or MySQL, and Elasticsearch or OpenSearch. CKAN needs Python, PostgreSQL, Solr and Redis. Confirm each dependency and its support window with the vendor before you commit to an architecture.
Upgrade and support planning
Catalogs change quickly, so plan for upgrades from the start. OpenMetadata 2.0 changed embedding credentials, the Databricks auth format and the ingestion image runtime, and it lists breaking changes that must be handled before upgrading. CKAN minor releases can include backwards-incompatible changes, while patch releases do not. Ask a partner how they will test each upgrade in a staging copy and keep the inventory evidence current through each change.
How the catalog builds and keeps the inventory current
The inventory is built in a fixed order: connect sources, harvest metadata, assign an owner to each dataset, apply classifications, then attach labels that match the classification scheme. Harvesting alone gives you a list of tables and dashboards, not an inventory that satisfies A.5.9, which asks for owners to be recorded against each asset. Start with the systems in scope for the ISO 27001 scope statement, such as the core banking extract, the HR database and the reporting warehouse, and confirm with the catalog vendor which connectors OpenMetadata or DataHub supports for each one. Then run a first harvest and count what appears against what your asset register already lists. The gap between the two is your first work list.
Ownership is a human decision that the tool records. Someone accountable for the business outcome must be named for each dataset, and the catalog stores that name, its role and the date it was set. Classification follows the same logic: the owner proposes a level based on confidentiality, integrity and availability needs under A.5.12, and the catalog then carries the label that flows to exports and reports under A.5.13. Automated rules can suggest tags, but they should not decide them. Lineage matters here because A.5.9 expects you to understand dependencies between assets. Table, column and pipeline lineage show which downstream reports depend on a classified source, so a change in one place is visible in another. Confirm with the vendor whether lineage is captured from OpenLineage events emitted by your pipelines, and whether the Python SDK can register custom assets such as file shares or SaaS exports that no connector covers.
Keeping the inventory current is an operating routine, not a project milestone. Set ingestion schedules so metadata is re-harvested on a cadence your data owners agree on, and alert on new assets with no owner. Run ownership reviews on a fixed calendar, with each owner confirming or reassigning their datasets, and record the result as evidence for the auditor. Decide in advance who handles owners who have left the organization and how orphaned datasets are escalated. Your certification body will look for this evidence across a full surveillance cycle, so the review log is as important as the inventory itself. Ask your implementation partner to show how the schedules, alerts and review records are configured and where they are retained.
What auditors ask to see from the catalog
Can the catalog produce a complete asset inventory export for an ISO 27001 audit?
Yes, if the catalog is populated with every in-scope data store, and the export is taken from the catalog itself rather than assembled by hand. The inventory is what A.5.9 asks for: a maintained list of information and associated assets, including their owners. In OpenMetadata or DataHub, the export is built from ingested entities such as databases, schemas, tables, dashboards and pipelines, each with a unique identifier, description and owner. Confirm with your auditor how they want the export delivered (spreadsheet, CSV or API extract) and record the date and the ingestion run it came from, so the list can be reproduced later. Gaps usually come from sources that were never connected, such as file shares or SaaS tools, so the scope statement should name them explicitly.
How does the catalog show the named owner for each dataset?
The catalog records ownership as an attribute on each entity, and the auditor will check that every in-scope dataset has one. A.5.9 expects owners to be recorded alongside the inventory, so the owner field must be filled in for each asset and must point to an accountable person or team, not a shared mailbox nobody monitors. OpenMetadata and DataHub both support owner assignment at the entity level, and many teams add a steward role for day-to-day curation. Run a report of entities with no owner before the audit, and decide in advance how orphaned datasets are handled, because the auditor will often sample a dataset that has no owner and ask why.
What evidence shows the classification scheme was approved?
The auditor expects a written classification scheme under A.5.12 and an approval record showing that management or the information owner signed it off. The catalog holds the operational version: classification levels as tags or a classification object, with a description of each level and the criteria used, based on confidentiality, integrity, availability and interested party requirements. The approval itself usually lives in the policy system, so link the scheme document to the catalog glossary or classification description, and keep the approval date and approver in the document, not only in the tool. Confirm the exact format of approval evidence with your certification body, since it is their call what they accept.
How are labels applied to datasets and where is the labelling procedure recorded?
A.5.13 asks for a procedure for labelling information in line with the classification scheme, so the auditor will want to see the procedure document and evidence that labels appear on the assets. In the catalog, labels are implemented as tags or glossary terms attached to tables, columns or dashboards, and the procedure should state which label applies to which class, who may apply or change it, and how labels reach downstream outputs such as reports or exports. Ingestion logs and tag history show when a label was applied by a process. Where labels are applied manually, state that in the procedure and keep the list of people with permission to edit tags.
Where can I find a change history for owner and classification edits?
Auditors often ask to see who changed a classification or owner, when, and why, and this depends on the audit logs enabled in the catalog and the database behind it. Confirm which version of OpenMetadata or DataHub you run and whether its audit or change events are retained, exported and protected from editing. Forward these logs to your central logging platform so they cannot be altered by catalog administrators. Ask your implementation partner to document the retention period and to test that a change to an owner or tag produces a traceable record. A change history without a reason field is weaker evidence, so require a ticket or request reference for significant reclassifications.
What review records prove the inventory and classifications are kept current?
The auditor will look for evidence that the inventory and classifications are reviewed at planned intervals, not only created once. The catalog supports this with ingestion run history showing that sources were rescanned, with stale or missing assets flagged, and with owner attestation records if the team uses review tasks or a glossary approval workflow. Record each periodic review as a dated meeting or sign-off with the owners who took part and the changes made. Choose a review cycle that your team can sustain, document it in the policy, and keep the records in the same place each time so they are easy to sample.
Will the auditor choose which datasets to check, or can we pick them?
The auditor chooses the sample. Certification bodies select the datasets, owners, labels and change records they test, and they usually do this from your exported inventory, so the catalog must be complete and consistent before the audit starts. You should not select or hide items in advance, and you should not present only the best-documented assets. Prepare by testing a random set yourself: pick several datasets, trace each one to its owner, classification, label and change history, and fix any gaps you find. Certification decisions are made by the accredited certification body, not by DeployOpen, which prepares systems and evidence but does not issue audit reports or certificates.
Can our own team prepare this evidence, or do we need an implementation partner?
Many organizations can prepare the evidence with internal staff, but the work is usually larger than it looks. Your team must decide scope, define the classification scheme, assign owners who accept accountability, and run the review cycle, which are management tasks no partner should own. The technical work of connecting sources, configuring tags, enabling audit log export and building the inventory export is where a partner can save time, provided the scope and deliverables are agreed in writing first. DeployOpen works on fixed-scope engagements for self-hosted open-source platforms in your own environment, and it does not issue the audit or certificate. Ask any partner to show a sample evidence pack built from your catalog before you sign.
What a data catalog alone does not satisfy
A catalog records what exists, who owns it and how it flows, but ISO/IEC 27001:2022 expects decisions, procedures and accountability that sit outside any software. The cards below are the gaps an assessor will probe first, and each one needs a named owner in the organization before the catalog goes live.
Classification scheme must come from policy
A catalog can hold classification tags, but it cannot decide what Confidential, Internal or Restricted mean for your organization. Under A.5.12, classification must reflect confidentiality, integrity, availability and interested party requirements, so the scheme is a policy decision signed off by management. Before configuring any tags in OpenMetadata or DataHub, confirm the scheme exists in writing, who maintains it and how exceptions are approved.
Labelling procedure needs documented steps
A.5.13 asks for procedures for labelling information in line with the adopted classification scheme. A catalog tag on a table does not label a report exported to a spreadsheet, a PDF or an email attachment. The labelling procedure must state where labels are applied, how they travel with copies and what happens when a label is missing or wrong, and the catalog should reference that procedure rather than replace it.
Owners must accept accountability in policy
A.5.9 requires inventory entries to include owners, but a field populated in a catalog is not an accepted accountability. Owners need a written role description covering approval of access, review cycles and classification changes, and they should acknowledge it through your normal policy process. Ask your assessor how they expect owner acceptance to be evidenced, since a catalog owner field alone is rarely enough.
Undocumented sources stay invisible
A catalog only inventories what its connectors can reach. Spreadsheets on shared drives, SaaS applications without a connector, paper records and systems under shadow IT will not appear, and an assessor testing the inventory against the asset list will find them. Confirm connector coverage against your asset register, and record the sources that must be added manually or excluded with a documented reason.
ISMS scope and risk assessment sit outside the tool
The catalog inventory feeds the ISMS, but the ISMS scope, the risk assessment methodology and the risk treatment decisions are not generated by any metadata platform. Decide which datasets fall inside the certification scope, and link catalog entries to the risk register through documented identifiers. The scope decision must come from the organization and be confirmed with its certification body, since the body audits the boundary it accepts.
Metadata accuracy depends on stewardship
Lineage, owners and classifications decay as pipelines change and teams reorganize. Automated ingestion keeps structure current, but it does not confirm that a dataset owner still works in the role or that a classification is right. Assign stewards with a review cadence, track stale entries and agree who corrects them. Ask how the catalog will show ownership gaps, since stale metadata is the most common finding in inventory reviews.
Rolling out the catalog against the Annex A controls
The sequence runs from agreeing the classification scheme with the ISMS owner to a documented, repeatable procedure that covers the inventory, ownership, classification and labelling evidence for A.5.9, A.5.12 and A.5.13. Each phase closes with a check the ISMS owner can review.
Agree the classification scheme and labels
Before any metadata is entered, the ISMS owner, with legal, privacy and the business data owners, defines the classification levels, the criteria for each level based on confidentiality, integrity and availability, and the label text and handling rules that go with each level. Results are recorded as a short scheme document that A.5.12 and A.5.13 can point to. The step is done when the ISMS owner signs off the scheme and the matching label set, and the catalog's classification tags are mapped one to one to those labels.
Deploy the catalog in your infrastructure
The implementation partner installs the chosen catalog, OpenMetadata or DataHub for internal governance or CKAN for a published portal, inside the organization's own cloud accounts or data centers, with its database, search service, SSO and backups in scope. Operators confirm the prerequisites for the chosen platform before installation and record the versions in the asset inventory itself. The step is done when the environment passes a documented smoke test, administrator roles are assigned and the deployment record is stored with the ISMS documentation.
Ingest the priority sources
Connectors are configured for the systems that hold the most sensitive or business-critical information first, such as core databases, warehouses, file stores and reporting tools. The team records which sources are in scope, which are deferred and why, so the inventory has a visible boundary. The step is done when each priority source appears in the catalog with its schemas, tables or objects and the coverage gaps are logged for follow-up.
Bootstrap owners with data stewards
Each dataset, table group or system is assigned a named owner and, where needed, a steward who maintains its description and classification. Owners are confirmed in writing by the business unit, because A.5.9 requires owners to be identified, not inferred from the technical account that loaded the data. The step is done when every in-scope asset has an owner and steward, and unowned assets are listed with a named person responsible for resolving them.
Classify and label a pilot domain
One business domain is chosen for a pilot, ideally one with clear owners and a mix of sensitive and non-sensitive data. Owners classify each dataset against the agreed scheme, automated tags are reviewed for false positives, and labels are applied in the catalog and carried into the places where the data is consumed. The ISMS owner reviews a sample of decisions. The step is done when the pilot domain has a complete, reviewed classification record and the team has a list of corrections to the procedure.
Expand to the remaining domains
The procedure from the pilot is applied to the remaining domains in an agreed order, with stewards trained on the scheme and the review steps. Lineage and new source onboarding are added to the same routine so that new assets enter the inventory before they go live. The step is done when every in-scope domain shows owners, classifications and labels, and the coverage report matches the scope agreed at the start.
Document the procedure and keep evidence
The team writes the operating procedure that describes how assets are added, owned, classified, labelled and reviewed, and defines who approves exceptions. Evidence is collected in a form an auditor can sample, including exported inventory reports, change history, owner confirmations and review minutes. Independent certification bodies decide whether this evidence meets the standard, and DeployOpen prepares it without issuing any attestation. The step is done when the procedure is approved by the ISMS owner and the first evidence pack is filed.
Where ISO 27001:2022 certification stands for this work
ISO/IEC 27001:2022 is the current edition of the standard, and it is the version a certification body will audit against for new and renewed certificates. Its Annex A is normative and lists 93 controls in four themes taken from ISO/IEC 27002:2022: organizational controls (clause 5, 37 controls), people controls (clause 6, 8 controls), physical controls (clause 7, 14 controls) and technological controls (clause 8, 34 controls). The three controls this page maps to, A.5.9 inventory of information and other associated assets, A.5.12 classification of information and A.5.13 labelling of information, all sit in the organizational theme. The transition from the 2013 edition ended on 31 October 2025, so an organization still holding a 2013-based certificate should already be planning its move to the 2022 control set.
The 2024 climate change amendment does not change Annex A. It adds a determination on whether climate change is a relevant issue to clause 4.1 and a note to clause 4.2 that interested parties can hold climate-related requirements. A data catalog project does not need new controls for it, but the scope and context documentation that feeds your risk assessment may need a short statement on climate relevance, and your auditor may ask for it.
Accredited certification bodies assess management systems against ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024, the latter of which IAF MD 29:2024 required all certification bodies to apply to their clients by 31 March 2026. Certification itself is issued by the certification body, not by ISO or by DeployOpen. Before scoping the catalog work, confirm with your certification body which evidence it expects for A.5.9 to A.5.13, how it samples datasets during audits, and whether it treats an automatically generated inventory as acceptable evidence. Those answers should shape the catalog design more than any general guidance does.
How much effort does an ISO 27001 catalog inventory take?
What drives the cost of an ISO 27001 catalog inventory?
The cost is driven by the number of sources to connect, how deep lineage must go, and how much owner and glossary work the organization must do by hand. The open source license carries no license fee: OpenMetadata and DataHub are both Apache-2.0, and CKAN is AGPL v3.0, so the spend is on infrastructure, setup, curation and operations. The main cost components are:
- Infrastructure for the catalog server, database and search service, which recurs every month.
- Connector configuration and lineage setup, which is largely one-time per source type but grows with each new system.
- Metadata curation and stewardship time, which recurs as systems and owners change.
- Services from an implementation partner, which are priced from the written scope.
Ask any quote to split these lines so you can see what is one-time and what recurs.
Can our team build the ISO 27001 catalog inventory alone?
Yes, if you have engineers who can run a Kubernetes or bare metal deployment and staff who can own the metadata. The catalog platform itself is installable from documentation. The harder part is the governance work: agreeing what counts as an information asset under Annex A control 5.9, assigning owners, and getting classification scheme decisions approved. Teams that take this on alone usually underestimate the owner interviews and the connector edge cases. A partner can take the platform build, connectors and hardening, while your compliance and data owners keep the decisions. Confirm the split in writing before work starts.
How long does a catalog inventory take to complete?
Duration depends mainly on the number of source systems, how many of them need custom connectors, and how quickly named owners respond. No general duration is supplied for this work, so treat any figure you are given as a claim to test. Ask the partner to break the timeline into phases: platform build, connector onboarding per source, owner bootstrapping, classification review and evidence capture. Owner availability is often the longest dependency, so ask for the dates on which you must supply people, not only the dates when the platform is ready.
What does the work need from our organization?
The work needs named owners for each dataset, an approved classification scheme for Annex A control 5.12, and a labelling procedure for control 5.13. It also needs read-only access to source metadata, service accounts for connectors, and a sponsor who can settle disputes about ownership. Expect your data owners to review draft entries, not to write them from scratch. Confirm before work starts who approves classifications, how often owners review their entries, and which systems are out of scope.
Does ISO 27001 certification depend on the catalog?
No. ISO 27001 requires an organization to maintain an inventory of information and associated assets with owners, but it does not require a specific tool. A catalog is one way to produce and keep that inventory current, and it can support the evidence an auditor reviews. Your certification body decides whether your inventory meets the standard. Ask the certification body early whether it expects a particular format or retention of change history.
Can DeployOpen certify our ISO 27001 inventory?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. ISO does not certify organizations either. Accredited certification bodies perform the audit, and they operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024. Ask your certification body to confirm which evidence it will sample from the catalog.
How do we keep the inventory current after the project ends?
The inventory stays accurate only if new systems are onboarded into the catalog and owners review entries on a schedule. Plan for recurring work: connector maintenance, catalog upgrades, and steward reviews when systems or teams change. OpenMetadata releases are frequent, and its 2.0 release includes breaking changes that require migration steps, so upgrades need a test plan. Ask whether support, upgrades and continuous review are covered by a retainer or by a separate agreement.
What to ask an implementation partner before you start
Start by asking which connectors the partner will configure in the first phase and which ones they will leave for later. For an ISO 27001 scope, the first set should cover the systems that hold information in the ISMS scope: the production databases, file shares, SaaS applications that hold confidential records, and the identity directory that supplies owner names. Ask for the connector list in writing, with the source version each one targets, and ask how they will handle ingestion credentials. Ask whether OpenMetadata ingestion will run inside your network and which service account it uses. Confirm each answer in the statement of work, because connector coverage is the first place an inventory quietly stops being complete.
Next, ask how ownership and classifications will be bootstrapped. A good partner will explain how the first owner assignments are drawn from your HR and service records, how owners are confirmed by the business, and how a dataset with no owner is flagged rather than left blank. Ask how the initial classification draft is produced, who approves it, and how the tags map to the confidentiality, integrity and availability levels in your classification scheme for A.5.12. Ask how labels are mapped to the ISMS procedure for A.5.13, meaning which label is applied where, and whether the mapping is written as a procedure your information security team signs off. Request a sample of the mapping table before work begins.
Finally, ask how upgrades and evidence exports are handled. The OpenMetadata 2.0 release notes list breaking changes, including moving embedding credentials into an llmConfiguration block and migrating Great Expectations to 1.3 before upgrading, so ask the partner to show a dated upgrade plan with a rollback step and a test of those changes in a non-production copy. Ask how the inventory, owner and classification records are exported (for example, through the REST APIs or a scheduled export), in what format, and how each export is kept as evidence for the auditor. Confirm that the partner does not issue audit results, since an accredited certification body makes that decision, and agree who keeps the export history.
How DeployOpen scopes and delivers a catalog for ISO 27001 evidence
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including metadata catalogs. For ISO 27001 work, we set the inventory and classification scope against the Annex A controls, build the catalog in your environment, and hand over the evidence and operating procedures your team and certification body will need.
How we scope
- Agree in writing which systems, databases and data stores enter the catalog inventory under control 5.9.
- Define the classification scheme and labelling rules that the catalog will carry for control 5.12 and 5.13.
- Confirm named owner roles per dataset, plus the steward and approval workflow for ownership changes.
How we build
- Deploy OpenMetadata or DataHub in your cloud account, data center or air-gapped network, with the database and search services.
- Configure connectors for in-scope sources, then test that inventory entries, owners and classifications appear as specified.
- Set up SSO and access policies so that only authorized roles can view, edit or change classifications.
How we hand over
- Document the inventory scope, classification scheme, labelling procedure and ownership model as operating records.
- Provide a mapping from each catalog feature to the related Annex A control so auditors can trace the evidence.
- Train data owners and stewards on maintaining entries, and agree a review cadence for inventory currency.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, including catalog version upgrades.
- Confirm with your certification body which evidence it expects, since DeployOpen prepares evidence but does not certify.
