Hacken Cybersecurity Compliance Service Methodology
Release: Version 2.0
Document
| Field | Description |
|---|---|
| Name | Cybersecurity Compliance Service Methodology |
| Creators | Hacken OU |
| Subject | compliance methodology; third-party assessment; implementation; evidence; non-conformity; independence; certification; |
| Description | A single, framework-agnostic methodology covering how Hacken delivers every cybersecurity compliance engagement — the two engagement types, the stages, the evidence rules, the finding taxonomy, the timelines, the independence rules, and the limits we will not cross. Framework-specific requirements are carried in per-framework annexes. |
| Author | Dmytro Yasmanovych | Head of GRC & Security Operations, Hacken OU |
| Date | Jul 22nd, 2026 |
| Applies to | All Cybersecurity Compliance engagements |
| Rights | Hacken OU |
Why there is one methodology
Frameworks differ in what they require. They barely differ in how you prove it.
DORA, VARA, ISO 27001, SOC 2, CCSS, MiCA and the rest ask overlapping questions, in a different order, using different words. The work of answering them is the same work: define the scope, find the gap, fix it, prove it, record what could not be proven. Maintaining ten methodologies for one process creates ten places for the process to drift.
So there is one:
- This methodology defines how Hacken works — the stages, the evidence rules, the finding taxonomy, the timelines, the independence rules, and the limits we will not cross.
- A framework annex defines what is assessed — the requirement source, its version, who it applies to, and the shape of the deliverable.
Two engagement types
Everything Hacken does in compliance is one of two things. The difference is not the framework. It is whether we are helping you build, or verifying independently.
| Specifics | Implementation | Third-Party Assessment |
|---|---|---|
| What we do | Build and prepare | Verify and attest |
| Our posture | We work as your in-house resource | We are independent of you |
| Typical trigger | You want ISO 27001 or SOC 2 and need to be ready | A regulator requires an assessment, or a certificate is needed |
| Remediation | We advise, draft and help implement | We confirm what is required and what is expected |
| Who certifies | An independent third party — never us | Hacken, where the scheme permits |
| Deliverable | Gap report, risk register, roadmap, evidence pack | Assessment report and/or certificate |
| Frameworks (typical) | ISO 27001, SOC 2, ISO 42001, NIST CSF, DORA | ADGM, BMA, BVI, CMA, CCSS, VARA |
We never do both for the same scope at the same time. See Independence.
APPLICABILITY CHECK
(assessment only)
│
┌───────────────┴───────────────┐
│ │
IMPLEMENTATION THIRD-PARTY ASSESSMENT
│ │
Gap Assessment Readiness Assessment
│ │
Risk Assessment Initial Assessment
│ │
Remediation (we help build) Remediation (you build, alone)
│ │
Follow-up Final Assessment
│ │
Certification support Report / Certificate
│
[independent body certifies]
Implementation engagements
Hacken helps you build. Hacken does not certify what it built.
Gap Assessment and scope applicability
We establish where you are against the target state, and what is genuinely in scope.
- We do: confirm the scope boundary — entities, systems, locations, data, third parties. Review your current state at control level. Identify blockers, dependencies and sequencing. Build the roadmap to the target state.
- You do: nominate a scope owner. Give us documents and access to the people who own the processes.
- Output: Gap Assessment Report and remediation roadmap.
This is not an audit. Findings here carry no certification weight and no external party relies on them.
Risk Assessment
A risk register is only useful when every risk carries an owner and a decision.
- We do: collect assets, business context and threat landscape. Work with you to define risk appetite and tolerance. Map threats to assets, determine likelihood and impact, establish inherent risk, identify existing and planned controls, assess control effectiveness, derive residual risk, agree treatment, and build the treatment roadmap.
- You do: asset owners, process owners, risk owners and management take part directly, at every stage.
- Output: risk methodology, risk register, risk treatment plan.
Every risk leaves this stage with a named owner and a decision. The aim is not a standalone document, but a sound basis for deciding where your security investment goes.
Remediation (consultative)
- We do: advise on the best-fit approach and solution, draft and review documentation, support technical implementation, research and help select tooling and architecture, bring the practice others use.
- Duration: minimum 20 business days, could be extendable to 40.
Follow-up
We re-check remediated items against the gap register and confirm closure, or record what is still open and why.
Output: updated gap register and a readiness statement.
Certification support
By this point we know your scope, context, processes, controls, owners and documents. So we run the certification process on your behalf: complete the application material, assemble the evidence pack, coordinate the audit schedule, and answer the certification body’s questions as if we were your team — because for this purpose we are. Anything we cannot answer, we come back to you for.
Please note: certification is issued by an independent body, never by Hacken.
Third-party assessment engagements
In these engagements Hacken acts independently. That independence is what gives the certificate its value.
Applicability Criteria Check
Some regulations are genuinely unclear about who they capture. If you need to know whether they capture you, this stage answers it — and you can buy it alone.
- We determine: your entity classification, which instruments and articles apply, which do not, available exemption or proportionality routes, the deadlines that bind you, and what non-compliance actually costs — penalties, licence risk, supervisory consequences.
- Output: Applicability Memorandum.
Readiness Assessment
The question this stage answers: do you have the minimum maturity for an audit that can actually finish?
- We do: request scope information and the core document set, review it against the requirements, and give you a verdict with reasons.
- Verdicts: go / conditional go, with named conditions / no-go, with what has to change first.
A no-go is a legitimate and useful outcome, and generally far less costly than an audit that cannot be completed.
Initial Assessment
We test every requirement in scope, using a minimum of two information-gathering techniques per requirement: interview, documentation analysis, observation, inspection.
Each requirement receives an outcome from the taxonomy below, together with its justification. Every finding records the reason it was raised.
Output: Initial/Preliminary Assessment Report, showing both what conforms and what does not.
Remediation (arm’s length)
You have 20 business days from delivery of the Initial Assessment Report, unless the framework annex sets otherwise.
During remediation the assessor will confirm what a requirement expects. The assessor will not design a solution, draft or review your documents, recommend a specific vendor, or pre-approve an approach.
Final Assessment
We re-test the remediated items under the same evidence rules applied in the initial assessment. Items still open at the end are recorded in the final report and on the face of the certificate as non-conformities or, where a requirement could not be tested, as unassessed.
Independence
Hacken provides both implementation and assessment services. The separation between them is set out here so that it is clear to everyone involved.
The rules:
- The assessor is never a person who worked on the implementation.
- Hacken does not assess a management system, control set or documentation that Hacken produced, implemented or maintained for the same scope, within two years of the end of that work.
- Prior professional or personal relationships between the assessor and anyone in the client’s assessed scope are declared before assignment, not discovered during the engagement. The same two-year rule applies.
- Where a relationship or any other factor means an assessor cannot proceed objectively, a different assessor may be assigned — on management approval and at the client’s request.
Evidence
Design and operation
Every requirement is tested twice: that the control is defined, and that it actually runs.
A policy proves the first. Only an artefact from the live system proves the second.
Two independent sources
Each requirement is assessed using a minimum of two of: interview, documentation analysis, observation, inspection. A single source indicates; two corroborate.
The format is open
There is no prescribed evidence format. We assess what demonstrates the control, in whatever form it exists.
We actively welcome GRC-engineering output: JSON exports, API responses, schemas, logs, technical records, configuration state, infrastructure-as-code, policy-as-code, pipeline output, tickets, pull requests. We equally accept management-signed statements, screenshots, recorded walkthroughs and reports.
The only condition is that the origin can be verified — that the configuration is reachable from your admin console, that the code is genuinely in the production repository, that the log came from the system it claims to come from.
If evidence cannot be provided in one form, tell us and we will name another that works. Where a particular artefact is unavailable, we will look for an alternative that demonstrates the same thing. What we cannot do is conclude that a control operates without seeing something that shows it.
Evidence period
Operating evidence must cover at least one full cycle of the control’s own frequency, or three months, whichever is longer. For annual controls, the most recently completed cycle.
Sampling
Where a control produces a population, the assessor selects the sample. Selection sits with the assessor rather than the client, and the sample size is recorded in the report.
Outcomes
| Outcome | Meaning | Effect |
|---|---|---|
| Conformant | Requirement met. Design and operation both evidenced. | — |
| Minor non-conformity | Isolated or partial failure. The intent of the requirement is still achieved. | Recorded. Does not block issuance. |
| Major non-conformity | Requirement absent, failed, or failing systemically. | Blocks issuance until closed. |
| Area of Concern | A significant risk identified during the assessment, including where it falls outside the requirements in scope. | Recorded in the report. Does not by itself block issuance. |
| Not Assessed / Not Tested | No information about the process was provided, so the requirement could not be tested. | Recorded with justification, visible in the deliverable. |
| Out of Scope | The requirement or area was not included in the agreed scope. | Recorded in the scope section of the deliverable. |
What each outcome states
A deliverable can make several distinct statements about a requirement, and they are not interchangeable:
| What we are saying | Outcome |
|---|---|
| We tested it and found it deficient | Minor or major non-conformity |
| We received no information about the process, so we could not test it | Not Assessed / Not Tested |
| It was agreed to sit outside the scope | Out of Scope |
An Area of Concern sits alongside these rather than among them. It records a significant risk identified during the assessment, including one that no requirement in scope covers, and it can be raised even where every requirement is met. We record a failure only where we tested for it. Where a process was not made available to us, we say so plainly rather than inferring a result, which keeps the deliverable accurate about what was and was not examined.
Major or minor
A finding is major if any of these is true:
- there is no control for the requirement at all;
- the control is defined but has never operated;
- the failure is systemic — it recurs across the population rather than in isolated instances;
- the failure defeats the intent of the requirement, even though the control formally exists;
- several related minor non-conformities together show the process is not functioning.
Otherwise it is minor.
Related minor findings are considered together. Several in the same process can indicate that the process as a whole is not working, and are then recorded as one major non-conformity.
What reaches the certificate
Non-conformities still open at the Final Assessment, areas of concern, unassessed requirements and anything recorded as out of scope appear on the face of the deliverable, not only in the body of the report. The reader should be able to see what was and was not verified without opening the full report.
The clock
Clear dates keep the engagement predictable for both sides.
- The Engagement Plan is the only source of dates. Dates agreed elsewhere are added to the plan before they take effect. This applies to us as much as to you.
- The remediation clock starts on the date the Initial Assessment Report is delivered to the channel of record — not when it is read, opened or acknowledged.
- One extension is available, requested in writing before the deadline expires, of up to 20 further business days. An extension can only be granted while the period is still open.
- Scope changes are recorded in writing, with their timeline impact, even when Hacken absorbs them at no additional cost. Recording them keeps both sides working from the same history.
- The engagement continues if one person is unavailable. This is why a deputy is named at the start.
Disputes, appeals and reassignment
You can challenge any finding. The route for doing so is technical rather than commercial.
- Appeal window: 10 business days from delivery of the report, in writing, with the rationale and any new evidence.
- Who decides: a qualified assessor who did not work on the engagement. The outcome and its reasoning are recorded in the engagement file and shared with you.
- Commercial escalation does not change a conformity determination. Findings are changed through technical review rather than through sales, delivery management or leadership. This protects you as much as us, and it is what gives the certificate its weight.
- Reassignment is available on management approval at your request. The engagement restarts from zero.
Who signs
- Every engagement has a named lead assessor, whose qualification against the framework is recorded before assignment.
- The conformity determination is made by the lead assessor and reviewed by a second qualified reviewer before any report or certificate is issued.
Two signatures mean the determination is the firm’s, rather than one individual’s alone.
The red lines
These five principles apply consistently across every engagement, every client and every timeline.
1. Zero Assumptions
No proof, no stamp.
We treat cybersecurity compliance assessment as a technical assessment. We assess evidence rather than assertions. Where evidence cannot be provided, the requirement is recorded as Not Assessed rather than as met.
2. Zero Delayed Compliance
No report is issued before sufficient evidence has been accepted.
Where evidence was not available within the assessment period, that is recorded in the report as a finding rather than left to be resolved afterwards.
3. Zero Conflict of Interest
The assessor works closely and professionally with the client while remaining independent. Where the two are in tension, independence takes precedence.
No prior professional or personal relationship influences a conformity determination. Prior relationships are declared before assignment and carry a minimum two-year separation. Where objectivity is compromised, a different assessor is assigned on management approval and at the client’s request — and the engagement restarts from zero.
4. Zero Paper Compliance
Documents describe. Evidence demonstrates.
We do not conclude compliance from policies, procedures and guides alone, as documentation shows how a control is intended to work rather than that it works. We accept evidence in any format, including technical and automated output, provided its origin can be verified. The format is flexible; the need to demonstrate the control is not.
5. Zero Open Endings
Every engagement ends in a deliverable that reflects what was verified.
Where a client stops collaborating and the timeline expires without a written extension request, Hacken issues the report “as-is”, with all non-conformities, areas of concern and unassessed requirements stated plainly. Where we receive no response, the report reflects what we were able to verify by the closing date.
Frameworks and requirements in scope
This methodology applies to every engagement against the frameworks and regulatory requirements below. The process is the same for all of them. The Engagement Plan records the framework-specific parameters for each engagement: requirement version, applicability, deliverable form, and regulator timelines.
Standards and certification schemes
| Framework | Requirement source | Engagement type | Deliverable |
|---|---|---|---|
| ISO/IEC 27001 | ISO/IEC 27001:2022 | Implementation, Certification Readiness | Certification readiness. Certification is issued by an accredited certification body. |
| ISO/IEC 42001 | ISO/IEC 42001:2023 | Implementation, Certification Readiness | Certification readiness. Certification is issued by an accredited certification body. |
| SOC 2 | AICPA 2017 Trust Services Criteria (revised points of focus, 2022) | Implementation, Audit Readiness | Attestation readiness. The attestation is issued by a licensed CPA firm. |
| NIST CSF | NIST Cybersecurity Framework 2.0 | Implementation; also used as assessment criteria | Gap report and roadmap |
| CCSS | CryptoCurrency Security Standard, Levels I–III | Third-Party Assessment, Certification | Audit report and CCSS certification |
| SEAL | Security Alliance (SEAL) certification frameworks | Third-Party Assessment, Certification | Assessment report |
Regulatory requirements: EU and Switzerland
| Framework | Requirement source | Engagement type | Deliverable |
|---|---|---|---|
| DORA | Regulation (EU) 2022/2554 and its RTS/ITS | Implementation / Third-Party Assessment | Gap report, Register of Information, roadmap; or assessment report |
| MiCA | Regulation (EU) 2023/1114, CASP governance and ICT requirements | Implementation | Licensing readiness and regulator interview preparation |
Regulatory requirements: UAE
| Framework | Requirement source | Engagement type | Deliverable |
|---|---|---|---|
| VARA (Dubai) | VARA Technology and Information Rulebook | Implementation / Third-Party Assessment | Licensing readiness; or assessment report |
| CMA (UAE, formerly SCA) | CMA Decision No. 4/R.M/2026: General Framework Module Ch. Three (Art. 47–53); Business Regulation Module Art. 99 and Annex 6 | Third-Party Assessment | External IT auditor report and certificates; annual wallet technology audit |
| CBUAE | Information Assurance Standard | Third-Party Assessment | Assessment report |
| ADGM – FSRA | FSRA Rulebook, systems and controls and virtual asset technology governance | Implementation | Authorisation readiness |
| ADGM – Registration Authority | DLT Foundations Regulations 2023 | Third-Party Assessment | Framework Security Audit Report for the Registrar |
Regulatory requirements: other jurisdictions
| Framework | Requirement source | Engagement type | Deliverable |
|---|---|---|---|
| BMA (Bermuda) | Digital Asset Business Act 2018; DAB Operational Cyber Risk Management Code of Practice | Implementation | Licensing readiness and audit support |
| SFC (Hong Kong) | Guidelines for Virtual Asset Trading Platform Operators (Type 1 and 7) | Implementation | Licensing readiness |
| BCR / CNAD (El Salvador) | BSP and DASP licensing requirements, cybersecurity provisions | Implementation / Third-Party Assessment | Gap report, policies; or assessment report |
AI governance
| Framework | Requirement source | Engagement type | Deliverable |
|---|---|---|---|
| EU AI Act | Regulation (EU) 2024/1689 | Implementation | Conformity readiness. Hacken is not a notified body. |
| NIST AI RMF | NIST AI 100-1 (AI RMF 1.0) | Implementation | Alignment assessment and roadmap |
| ISO/IEC 27090 | AI security guidance, not certifiable | Implementation | Used as assessment criteria |
Review of this methodology
- Owner: Head of GRC & Security Operations.
- Review: annually, and on any change to the service model, the finding taxonomy or the red lines.
- Version binding: each engagement is governed by the methodology version named in its Engagement Plan. A published change applies to engagements signed after its effective date. We do not change the rules on you mid-engagement.
Appendix A — Definitions
Terms are grouped by what they do: how we look, what we look at, what we conclude, and who does it.
Two words carry the most confusion in this industry, so read these first. Observation is a technique in this methodology rather than a finding. Non-compliance is not a synonym for non-conformity; see below.
Engagement terms
| Term | Definition |
|---|---|
| Implementation | An engagement where Hacken helps build and prepare. We act as your in-house resource and do not certify the result. |
| Third-Party Assessment | An engagement where Hacken verifies and attests independently. Also called external assessment. Where the scheme permits, Hacken issues the certificate. |
| Audit | Used interchangeably with third-party assessment in this document. Where a framework reserves “audit” for a specific regulated activity, its annex says so. |
| Scope | The entities, systems, locations, data, processes and third parties the engagement covers. Fixed in the Engagement Plan before work starts. |
| Scope unit | A separately assessable and separately issuable part of the scope. One engagement can produce several deliverables, each covering one scope unit. |
| Engagement Plan | The document fixing scope, dates, deliverables, named contacts, channel of record and methodology version. The only source of truth for all of them. |
| Channel of record | The single named channel where evidence is submitted and decisions are recorded. Material shared elsewhere is registered once it is added there. |
| Framework annex | The framework-specific companion to this methodology. Carries only what genuinely differs; everything else is inherited. |
| Requirement | A single obligation drawn from the framework, at the level the framework states it. The unit everything else is measured against. |
| Control | What the entity does to satisfy a requirement. |
| Criterion | The standard the assessor tests the requirement against. |
| Applicability | Whether a framework — or an individual requirement inside it — captures this entity at all. |
| Exclusion | A requirement or area deliberately placed outside scope, with a documented justification. Recorded as Out of Scope and visible in the deliverable. |
| Proportionality | A framework’s own provision allowing lighter application of a requirement based on size, risk or complexity. Applied only where the framework provides for it. |
| Initial Assessment | The first full test of every requirement in scope. |
| Remediation period | The window to close findings. Starts when the Initial Assessment Report reaches the channel of record. |
| Final Assessment | The re-test of remediated items only, under identical evidence rules. Produces the issued deliverable. |
| Follow-up | The implementation equivalent of a final assessment — confirmation that remediated items are in place. Carries no certification weight. |
How we look — information-gathering techniques
Every requirement is assessed using at least two of these.
| Technique | What it means |
|---|---|
| Interview | We ask the person who performs the control how it works, then compare the answer against what we see elsewhere. Interview establishes how the control is understood by the people who run it, and is always corroborated by at least one other technique. |
| Documentation analysis | We read the policy, procedure, standard, register or record and assess whether it defines the control adequately. Establishes design, not operation. |
| Observation | We watch the control being performed, or watch the process running in its live environment. Establishes that the activity happens as described. |
| Inspection | We examine the artefact or system state directly — a configuration, log, ticket, repository, console view, export. Includes technical re-performance, where the assessor runs the check themselves. The strongest evidence class. |
What we look at — evidence terms
| Term | Definition |
|---|---|
| Evidence | Anything that demonstrates a control exists and operates, in any format, whose origin can be verified. |
| Design evidence | Shows the control is defined — a policy, procedure, standard, configuration baseline. Proves intent. |
| Operating evidence | Shows the control actually ran — a log, ticket, export, record, approval, or live system state. Proves reality. |
| Provenance | The verifiable link between evidence and the system it claims to come from. Evidence whose origin cannot be traced cannot be relied on. |
| Evidence period | The window operating evidence must cover: one full cycle of the control’s own frequency, or three months, whichever is longer. |
| Population | The full set of items a control produced during the evidence period — every access review, every change, every incident. |
| Sample | The subset the assessor examines. Selected by the assessor rather than the client. Size recorded in the report. |
| Sufficient evidence | Covers both design and operation, from at least two techniques, with verifiable provenance, across the evidence period. Volume does not substitute for any of these. |
What we conclude — outcomes and findings
| Term | Definition |
|---|---|
| Finding | Any recorded conclusion against a requirement other than “conformant”. Every finding carries a stated justification. |
| Gap | The distance between current state and required state. Used in implementation, where nothing is being certified and nobody external relies on it. |
| Issue | Informal. Does not appear in Hacken deliverables. What is casually called a “minor issue” or “major issue” is recorded as a minor or major non-conformity. |
| Conformant / In Place | Requirement met. Design and operation both evidenced. |
| Minor non-conformity | A partial or isolated failure. The intent of the requirement is still achieved. Recorded; does not block issuance. Example: the control operates, but one month in six has no record. |
| Major non-conformity | The requirement is absent, has failed, or is failing systemically. Blocks issuance until closed. Example: the control is fully documented and has never been performed. |
| Non-conformity | A failure against a framework, standard or scheme requirement. This is what we record. |
| Non-compliance | A failure against a binding legal or regulatory obligation. Broader, and it carries consequences we do not set. We determine non-conformities. Only a regulator determines non-compliance. |
| Area of Concern | A significant risk identified during the assessment, including one that falls outside the requirements in scope. Raised because it matters to your security position, not because a requirement failed. Recorded in the report and, where material, shown on the certificate. |
| Not Assessed / Not Tested | No information about the process was made available, so the assessor could not test the requirement. Recorded with justification and visible in the deliverable. |
| Out of Scope | The requirement or area was not part of the agreed scope. Recorded in the scope section of the deliverable, together with the reason. |
| Blocker | Something that stops the assessment proceeding at all — no confirmed scope, no access, no named contact. Distinct from a finding, and raised immediately rather than at reporting. |
What the deliverable actually says
| Term | Definition |
|---|---|
| Assessment report | States what was assessed, what was found, and what could not be concluded. Issued in every engagement. |
| Applicability Memorandum | Output of the applicability check: which instruments capture you, in what capacity, by when, and what non-compliance costs. |
| Gap Assessment Report | Output of an implementation gap assessment: current state against target state, plus the roadmap. Not an assurance product — no external party relies on it. |
| Readiness statement | A go / conditional-go / no-go verdict on whether an audit can meaningfully start. Not an assurance product. |
| Attestation | A statement by Hacken about the outcome of work Hacken performed. |
| Certificate | A statement that a defined scope was assessed against defined requirements on a defined date, with outcomes shown on its face. A record of verification — not a guarantee of security. |
| Validity | A certificate speaks to the state observed during the assessment period. It says nothing about any later date. |
Independence terms
| Term | Definition |
|---|---|
| Impartiality | Absence of bias in the conformity determination. |
| Independence | Structural separation between the people who build and the people who verify. |
| Conflict of interest | Any relationship, interest or pressure that could reasonably be seen to influence a determination — whether or not it actually does. Perception alone triggers the duty to declare. |
| Declaration | The record of a relationship or interest, made before assignment. Conflicts are intended to surface here rather than during the engagement. |
| Cooling-off period | The minimum time between prior involvement with a scope and assessment of it. Two years. |
| Reassignment | Replacing the lead assessor, on management approval at the client’s request. Changes who performs the assessment, but not its scope or requirements. The engagement restarts from the beginning. |
| Technical review | The second-reviewer check before issuance, and the route through which a determination can change. |
Risk terms
| Term | Definition |
|---|---|
| Asset | Anything of value that needs protection — systems, data, people, facilities, third-party services. |
| Threat | A potential cause of an unwanted incident affecting an asset. |
| Inherent risk | The risk before any control is applied. |
| Residual risk | The risk remaining after existing controls — assessed for effectiveness, not assumed to work. |
| Risk appetite | The amount and type of risk the entity is willing to pursue. Set by your management, not by us. |
| Risk tolerance | Acceptable variation around appetite for a specific risk. The threshold at which action stops being optional. |
| Control effectiveness | Whether a control actually reduces the risk it was designed to reduce. Evidenced, not assumed. |
| Risk treatment | The decision: mitigate, transfer, avoid, or accept. Every risk gets one, and every treatment gets a date. |
| Risk owner | The named individual accountable for the risk and its treatment decision. Ownership sits with an individual rather than a team. |
Roles
| Role | Accountable for |
|---|---|
| Lead assessor | Performing the assessment and making the conformity determination. Named before work starts, qualification recorded. |
| Technical reviewer | Reviewing the determination before anything is issued. Never the lead assessor. |
| Scope owner (client) | Confirming what is in scope, and that the confirmation is accurate. |
| Primary contact (client) | Day-to-day coordination and evidence submission. |
| Deputy (client) | The same authority as the primary contact, including authority to release evidence. Named so one person’s absence cannot stall the engagement. |
| Certification body | The independent third party that certifies in implementation engagements. Never Hacken, for the same scope. |
For onboarding, please fill our Hacken Compliance Services Form.