Compliance Frameworks and Certification Standards Questions

Direct answer. A SOC 2 Type I report says your controls were designed properly on one date. A Type II report says they actually operated across an observation window (the period the auditor tests, agreed with the audit firm). A "clean" Type II means an unqualified opinion: the auditor concludes the controls were described fairly and operated effectively, even if a few deviations are listed. A qualified opinion means the auditor found that one or more criteria were not met and says which. To get a clean Type II, every control needs a named owner, a calendar for when it runs, and evidence captured when it runs, and any exception is handled the same week, not at audit time.

What I would put in place for the window

1. Control calendar. A list of every control with frequency and owner. Daily or event-driven controls (new-hire access, change approvals) are tested by sampling many instances: the auditor pulls a subset of the occurrences in the window and checks each one for the evidence the control promises. Illustrative example: if 60 new hires got access during the window, an auditor might pull 25 and check each for a ticket, a named approver and a date before access was granted. One grant with no approver is a deviation, 1 of 25, or 4 percent. Sample sizes are the audit firm's call and grow with the number of occurrences, so ask yours how it sizes them. Periodic controls (quarterly access review, annual risk assessment, annual policy review) are tested by whether each occurrence happened.
2. Freeze control design. Changing how a control works mid-window means the auditor tests two versions. Agree changes with the auditor and make them at the start where possible.
3. Ticketed evidence. Access grants, offboarding, change approvals and vendor reviews each leave a record that shows who approved what and when, produced as the work is done.
4. Monthly internal check. Someone other than the owner spot-checks a few instances per control (for example 3 to 5 recent access grants), so a failing control is found in weeks, not at audit.
5. Exception log. A deviation (a control instance that did not operate as described) is logged with cause and fix. The auditor reports deviations, so honest handling matters more than hiding.
6. Evidence automation (pulling records from systems automatically) is useful later and not needed to start.

Worked example. The window is 12 months and the quarterly access review is a control. The auditor expects four occurrences. If one quarter is skipped, the deviation rate is 1 of 4, or 25 percent, and a missed periodic control is hard to repair after the fact. A recurring calendar task with a named backup reviewer prevents this.

Keeping the program from decaying between audits

• Put control ownership in role descriptions and onboarding, so turnover does not orphan controls.
• Run a quarterly management review (a short meeting where leadership looks at open exceptions, controls trending late, and vendor and risk changes, and records what it decided).
• Track a few leading indicators, meaning early-warning measures that move before an audit failure does (late access reviews, overdue vendor assessments, open exceptions by age).
• Update scope when the system changes (new service, new vendor) before the next window.
• Hold a mid-year dry run so the annual audit is routine.

Pitfall. Treating Type I as the finish line. The effort is the habit, and the report is the evidence of it.

Direct answer. Diagnostic software is regulated as a medical device, so the question is no longer "which certificate" but "what does the regulator require before and after I sell it". I would treat safety risk management, software lifecycle, validation, cybersecurity and post-market monitoring as one evidence set, owned with a regulatory affairs lead. Counsel and regulatory affairs decide classification. Lead with the regime of the market you sell into: the US (FDA) if selling in the US, the EU (MDR, the Medical Device Regulation) if selling in Europe, and both if you sell in both. Terms: SaMD (software as a medical device) is software that performs a medical purpose on its own rather than running inside a hardware device, for example an app that flags findings on scans. Three international standards anchor the evidence in every market: ISO 14971 (medical-device risk management), IEC 62304 (software life cycle) and ISO 13485 (quality management system). Regulator terms: a clearance or approval is the regulator's permission to market the device; residual risk is the risk left after controls are applied; post-market surveillance is the monitoring you must keep doing after launch.

What governs each stage

Differences from ISO 27001 or SOC 2. The law requires a regulator's decision on the product, the focus is patient safety, and evidence is about this product and its intended use. ISO 27001 and SOC 2 are voluntary and organization-wide, and they do not address clinical safety. In Europe, software that informs diagnosis is usually Class IIa or higher (a mid-level risk class that requires a notified body, an independent assessor, to review the file) under MDR Rule 11 (explained in guidance document MDCG 2019-11), and EN 62304 is the European edition of the software life cycle standard that supports conformity.

Worked example: one traceable row

The same row with illustrative values. ISO 14971 does not prescribe a numeric scale, so each manufacturer defines its own in its risk management plan. Suppose severity is scored 1 to 5 and probability 1 to 5. A missed finding delays a diagnosis: severity 4. Before controls, probability is 3 (occasional), so risk is 4 x 3 = 12, above the acceptance limit of 8 in the plan. Controls: the screen shows the model's confidence and a clinician must review every case. Verification: on a test set of 400 cases that each contain the finding, the model flags 372, a sensitivity of 372 / 400 = 93%, so 28 are missed by the model alone; in a usability test, reviewers catch most of those 28, which supports lowering probability to 2. Residual risk is 4 x 2 = 8, at the limit. Benefit-risk sign-off (the documented decision by named clinical, safety and regulatory owners that the benefit of the device outweighs the remaining risk) records why 8 is acceptable and what post-market monitoring will watch.

Safety case (the file of reasoned argument that the product is acceptably safe). Argue, with evidence, that the product is acceptably safe: hazards, controls, tests, labeling and monitoring. Security frameworks supply the cybersecurity controls inside that argument. For AI that learns, FDA's final guidance on predetermined change control plans (December 4, 2024) lets planned updates be pre-authorized.

Direct answer

ISO/IEC 27001 is an international standard for running an ISMS (information security management system): the set of policies, processes, roles and records an organization uses to manage information security risk continuously. "ISO 27001 certified" means an independent certification body (a company that is itself formally approved, or accredited, to issue such certificates) audited your ISMS and found it conforms. It certifies the management system for a defined scope, not that you are unhackable. Certification is voluntary unless a law or contract demands it.

What an ISMS consists of

• Scope and context: which business units, systems, locations and interested parties (customers, regulators) the ISMS covers.
• Leadership and policy: a management-approved security policy, named roles, resources.
• Risk assessment and treatment: you identify risks, rate them, and decide what to do about each, with a documented plan. The four treatment options are: reduce (add a control), accept (knowingly live with it), transfer (shift the cost, for example with insurance or a contract) or avoid (stop the risky activity). Example: the risk of a customer database leaking from a stolen laptop is reduced by disk encryption, partly transferred by cyber insurance, and avoided entirely by not keeping production data on laptops.
• Statement of Applicability (SoA): a list of the Annex A controls (the standard's reference catalogue of security controls) you selected or excluded, with a reason for each. The SoA is how the control set is tailored to you, whichever Annex A edition applies. The 2022 edition lists 93 controls in four themes: organizational, people, physical and technological. You do not implement all 93 by default: you go through the list, include the ones your risks call for and justify each exclusion. Two illustrative rows: A.8.8 (management of technical vulnerabilities) is included because the product is internet-facing and vulnerability exposure is a rated risk; A.8.30 (outsourced development) is excluded because all development is done by employees, so the control has nothing to apply to.
• Operation and monitoring: controls run, are measured, and are audited internally.

How it is kept running (PDCA)

PDCA means Plan, Do, Check, Act. Plan: scope, risk assessment, objectives. Do: implement controls and the treatment plan. Check: monitoring, internal audit, and a management review, a recorded meeting where leadership examines audit results, incidents and risk changes and decides on actions. Act: corrective actions and continual improvement. Then the cycle repeats.

What the auditor looks at

The certification body audits in two stages: first a documentation and readiness review, then an on-site or remote check that the ISMS is implemented and working. After certification there are surveillance audits (shorter check-ups, usually yearly, to confirm the ISMS is still running) and a full recertification every three years. Three common documentary items: the risk assessment and treatment plan, the SoA, and records of internal audit and management review (with corrective actions).

Why it matters to customers

It gives buyers independent evidence of a managed, repeatable security program, is recognized internationally, and often shortens security questionnaires. Tell the CEO plainly: decide the scope first, because a narrow scope is cheaper but only protects what it names.

Direct answer. I would sort the four gaps by two questions: will the auditor treat this as missing a required element (frameworks such as ISO 27001 and SOC 2 both expect a working incident process and a record of what assets exist; the exact wording differs, so name your framework to the auditor early), and does leaving it for 90 days create real exposure? The incident response plan and the asset inventory block certification. Unencrypted backups and inconsistent MFA are real risk and I would start fixing them in the first 30 days anyway (the high-exposure part first, the rest by day 60 as the table shows), because they are cheap to fix and costly to explain.

Decision rule. A gap blocks if (a) the framework requires it as a defined, working element, so an auditor will record a major finding (a serious failure to meet a requirement, which can stop certification) without it, or (b) its absence makes other controls untestable. A gap is schedulable if a partial control exists, residual risk is low and a dated plan is approved by a named risk owner (the person with authority over the system who accepts the remaining risk). The exact calls depend on the framework and the auditor, so I would confirm with the auditor in week one rather than assume.

90-day plan (three 30-day blocks)

• Days 1-30: the four fixes above in minimum form, and auditor confirmation of what counts.
• Days 31-60: complete MFA, finish the inventory, restore test, update the risk assessment using the new inventory.
• Days 61-90: collect evidence, run a mock audit (an internal dry run), close findings and brief the risk owners on what is accepted. The final week is buffer, not work.

Pitfall. Do not use the 90 days to fix everything. A realistic plan documents accepted gaps in a risk register (a list of known risks) with an owner and date, for example: "Legacy admin console lacks MFA | compensating control: reachable only from the VPN | owner: head of IT | review by day 90". An auditor can accept that, and it does not claim controls that have no evidence.

What would change my call. If the audit is a Type I (a SOC 2 report on controls at a single date) or other point-in-time check, evidence of operation matters less and I could shorten the timeline. If the framework requires a period of operation, I would ask the auditor whether the audit date can move.

Direct answer

Build a common control framework: a single library of controls, each written once to meet the strictest overlapping requirement, mapped to every framework and law, tested on one calendar, with one evidence set and one owner. A GRC (governance, risk and compliance) function owns the library; control owners in engineering, IT and HR own execution; a steering group (a cross-team committee of senior owners that decides disputed exceptions) arbitrates exceptions. Where a law is involved, counsel decides what the law requires.

Build steps

1. Inventory each framework and law with its scope and audit rhythm.
2. Cluster requirements by domain (access, logging, change, vendors, incident response, retention, privacy rights).
3. Write one control per cluster at the strictest parameter.
4. Map each to every source with a coverage rating (how much of the source requirement the control meets: full, partial or gap). A sample control, as written: "AC-04: Access to production systems is reviewed every quarter by the data owner and unneeded access is removed within 5 working days" (illustrative), mapped to ISO 27001 Annex A 5.18, SOC 2 CC6.2 and CC6.3, and NIST CSF PR.AA-05, all rated full.
5. Test once, reuse the evidence across auditors.

Ownership

Library and mapping: GRC lead. Each control: a named operational owner. Exceptions and conflicts: a security steering committee. Legal interpretation: counsel.

Handling a framework revision

Treat it as a change request: obtain the new text, run a delta analysis (a line-by-line comparison of the new text with the old, listing what is new, changed or withdrawn) against the library, update or add controls, re-map, set remediation dates against the framework's own transition deadline (the date after which the old version is no longer accepted for audits), tell owners, and keep a dated change log so older audits can still be traced.

Where gaps and conflicts show up (three gaps, with remediation)

A parameter mismatch worked with values (illustrative): PCI DSS Requirement 10.5.1 asks for audit log history of at least 12 months, with the most recent 3 months immediately available for analysis, while ISO 27001 leaves retention to the risk assessment. The strictest value, 12 months, becomes the baseline for the systems in PCI scope; applying it to every system would keep personal data in logs longer than needed, so other systems follow the shorter retention schedule shown in the next paragraph.

A conflict, not just a gap: security logging wants long retention while privacy law pushes data minimization (keeping only the personal data needed, and for no longer than needed, GDPR Art. 5). Resolve with a retention schedule by log type approved by security and counsel: for example, payment-system audit logs 12 months with 3 months searchable; other application and infrastructure logs a shorter period such as 90 days (illustrative, set by security and counsel from the risk assessment); identifiers pseudonymized, and no card data or message content in any of the logs.

Audit-ready reuse

Tag every evidence artifact (access review export, change ticket sample) with the controls and frameworks it supports, and store it once.