IEEE 7000 Ethical Design Implementation: A 10-Step Value-Based System Design Process

COMPEL Body of Knowledge — Regulatory Bridge Series Cluster A Companion Article — Ethical Design Implementation

Why IEEE 7000 matters {#why}

Most AI governance programs succeed at documenting what a system does and how well it performs. Far fewer can produce auditable evidence of why the system was built the way it was — what values shaped its scope, which trade-offs were weighed against whose interests, and how those decisions were translated into concrete engineering requirements. That gap is the space IEEE 7000-2021 — Standard Model Process for Addressing Ethical Concerns During System Design is designed to close.

IEEE 7000 was ratified in September 2021 as the first standard to define a repeatable process for integrating ethical considerations into the systems engineering lifecycle. It does not dictate which values an organization must prioritize; instead it prescribes a process for surfacing the values that matter to stakeholders, translating them into engineering artifacts, and retaining the evidence trail so that later reviewers — auditors, regulators, affected communities — can reconstruct the reasoning.

Running IEEE 7000 solves three problems that purely outcome-based frameworks leave open:

1. The values-to-requirements gap. Frameworks like NIST AI RMF and ISO 42001 name trustworthy characteristics (fairness, transparency, accountability) but stop short of specifying how those abstractions become testable requirements. IEEE 7000 closes the gap through its Ethical Value Requirements (EVRs) construct.
2. The affected-community blind spot. NIST AI RMF GOVERN 5 and ISO 42001 clause 4.2 both require interested-party engagement but leave the how to the implementer. IEEE 7000 provides elicitation techniques — workshops, surveys, ethnography, adversarial analysis — that generate defensible stakeholder coverage.
3. The design-rationale audit trail. Regulators increasingly ask “show me the record of the decision” rather than “show me the outcome.” IEEE 7000’s transparency and accountability management steps generate that record by design.

Read the standard alongside the NIST AI RMF to ISO 42001 crosswalk: the crosswalk tells you what evidence to collect, IEEE 7000 tells you how to generate that evidence from stakeholder values rather than from abstract principles.

The 10-step process {#process}

IEEE 7000 organizes ethical design into ten interacting steps. In practice they overlap rather than run strictly sequentially — early steps iterate as later steps surface new information.

1. Concept Exploration

The system is described in ethical terms before it is described in technical terms. Teams state the problem the system intends to solve, the population it will affect, the ethical tensions the problem inherently carries (for example, accuracy versus privacy, accessibility versus security), and any red-line exclusions. A two-page ethical concept brief is the typical artifact. Good briefs answer: who benefits, who is exposed to harm, who decides, and who is silent?

2. System-of-Interest Analysis

The team maps the system boundary, adjacent systems, data flows, and — crucially — all stakeholders, not only the buyers. IEEE 7000 distinguishes direct users, indirect users, affected non-users, decision-makers, and operators. Each category matters because values differ sharply across them. A fraud-detection system’s direct users (bank analysts) value precision; its affected non-users (customers denied credit) value recourse and explainability. The output is a stakeholder register with demographic, power, and exposure attributes.

3. Ethical Values Elicitation

For each stakeholder group the team elicits the values relevant to this system. Values are not invented — they are surfaced through structured techniques described in the value elicitation techniques section. The output is a prioritized value list per group, with disagreement explicitly preserved rather than averaged away. For a loan-decisioning system, customers typically prioritize fairness and recourse; regulators prioritize non-discrimination; analysts prioritize explainability; shareholders prioritize loss ratios. All four lists are kept distinct.

4. Ethical Requirements Definition

Values are translated into Ethical Value Requirements (EVRs) — testable, assignable statements of what the system must do (or must not do) to honor each value. Each EVR records its source value, source stakeholder group, acceptance criteria, and verification method. This step is where IEEE 7000 becomes concrete; it is also where abstract ethical debate ends and engineering design begins. Examples appear in the EVRs section.

5. Risk-Based Design

EVRs are weighed against each other and against technical, financial, and schedule constraints. Trade-offs are explicitly recorded rather than silently resolved. If a privacy EVR and an accuracy EVR conflict, the team documents the options considered, the reasoning, and the stakeholder voices consulted. The output is a design decision log — the single most valuable artifact for later audits under the EU AI Act and ISO 42001 clause 8.2.

6. Transparency Management

The team defines what will be disclosed, to whom, in what form, and when. Transparency is decomposed by audience: end users get plain-language explanations; operators get operational documentation; auditors get the full design decision log; affected non-users get channels to request information. The artifact is a transparency plan that maps each disclosure obligation (regulatory, contractual, ethical) to a specific document, channel, and owner.

7. Accountability Management

For each EVR, a responsible role is named. For each foreseeable failure mode, an escalation path is defined. For each stakeholder grievance channel, a response protocol is established. This step answers the auditor’s perennial question: “when this fails, who owns the fix, and how long do they have?” The output combines a RACI matrix with an incident-response playbook keyed to EVRs.

8. Ethical Operational Integration

EVRs are turned into runtime hooks: monitors, alerts, logs, and controls that enforce the EVRs during operation. A “no inference on users under 13” EVR becomes an input validator and an audit-log rule; a “fair error-rate parity” EVR becomes a scheduled fairness test with threshold alerting. The output is a control specification linking each EVR to its runtime enforcement mechanism.

9. Risk Review

Periodically (typically quarterly, and after any material system change) the team reassesses whether the EVRs still reflect stakeholder values and whether the system still honors the EVRs. New stakeholder groups may have emerged; new risks may have materialized; earlier trade-offs may have become obsolete. The output is a risk-review memo that either confirms the current design or triggers targeted re-work.

10. Continuous Improvement

Lessons from risk reviews, incidents, and stakeholder feedback feed into two loops: improvements to this specific system, and improvements to the organization’s IEEE 7000 playbook. Common improvements include expanding the value library, tightening elicitation techniques, and adding new EVR templates. Over time, the organization’s IEEE 7000 capability becomes a reusable asset rather than a per-project cost.

Value elicitation techniques {#elicitation}

IEEE 7000 does not prescribe a single elicitation technique. It expects the team to select techniques based on stakeholder accessibility, time budget, and the sensitivity of the values being surfaced. The five techniques below cover the majority of practical situations.

In practice a single project runs three to five of these techniques in parallel and triangulates the results. The triangulation itself is evidence: showing that the same value appeared across workshops, surveys, and adversarial review defends the EVR against later “we weren’t consulted” claims.

A useful sequencing heuristic: begin with document review (cheap, establishes baseline), follow with workshops (depth with accessible stakeholders), run surveys for scale, commission ethnography where values are tacit, and close with adversarial analysis to stress-test the picture.

Ethical Value Requirements examples {#evrs}

Each EVR must be testable. Vague statements like “the system will be fair” are not EVRs; they are values. An EVR translates a value into a verifiable engineering requirement. The table below shows representative EVRs across the five most commonly surfaced value categories.

Well-formed EVRs share four properties: (1) they are verifiable with a specific method; (2) they are owned by a named role; (3) they carry an acceptance threshold that is either numeric or boolean; and (4) they are traceable to a value and a stakeholder group.

Traceability: value → requirement → control → evidence {#traceability}

IEEE 7000 is ultimately an evidence discipline. The entire process collapses into a traceability matrix that an auditor can walk end-to-end.

This matrix is the single artifact that satisfies the largest number of overlapping obligations: NIST AI RMF MAP 1.6, MAP 2.3, and MANAGE 2; ISO 42001 clauses 6.1.4 and 8.2; EU AI Act Article 9 risk-management documentation; and internal audit trails. Maintaining the matrix as living documentation — not a one-time deliverable — is what separates organizations that merely ran IEEE 7000 from those that operate it.

Mapping to COMPEL stages {#compel-mapping}

COMPEL’s six stages provide a natural scaffold for running IEEE 7000. Each IEEE 7000 step slots into a COMPEL stage without restructuring either framework.

The mapping makes IEEE 7000 operable inside the COMPEL rhythm teams already run. Calibrate and Organize-stage gate reviews validate that elicitation is complete before any EVR is drafted; Model-stage reviews validate EVRs before design freeze; Produce-stage reviews validate runtime controls before launch; Evaluate and Learn close the loop with lived operational data.

Evidence artifacts {#evidence}

A complete IEEE 7000 implementation produces the following artifacts. Each maps directly to one or more steps and is retained for the life of the system plus the longer of three years or the applicable regulatory retention period (EU AI Act Article 18 requires ten years for high-risk systems).

• Ethical concept brief (step 1)
• Stakeholder register with power, exposure, and demographic attributes (step 2)
• System-of-interest diagram with boundaries, data flows, and actor map (step 2)
• Elicitation plan and records — workshop minutes, survey results, ethnography notes, adversarial analysis memos (step 3)
• Prioritized value list per stakeholder group, with preserved disagreement (step 3)
• EVR register with source, acceptance criteria, owner, and verification method (step 4)
• Design decision log with trade-off rationale and stakeholder voices consulted (step 5)
• Transparency plan with disclosure-to-audience mapping (step 6)
• Accountability RACI and escalation playbook (step 7)
• Control specification linking EVRs to runtime monitors, alerts, and logs (step 8)
• Risk-review memos per review cycle (step 9)
• Continuous-improvement log and playbook updates (step 10)
• Traceability matrix (spans all steps)

When IEEE 7000 runs inside an ISO 42001 management system, these artifacts satisfy clauses 6.1.4 (AI system impact assessment) and 8.2 (system design) without duplication. When it runs alongside NIST AI RMF, the same artifacts satisfy MAP 1.6, MAP 2.3, MAP 3.1, and MAP 5.1.

Metrics {#metrics}

Teams that operate IEEE 7000 — as distinct from teams that merely documented it once — report on the following metrics:

• Stakeholder coverage ratio — percentage of identified stakeholder groups with recorded elicitation artifacts (target: 100%; weighted toward affected non-users)
• EVR verification rate — percentage of EVRs with a completed verification test in the last review cycle (target: 95%+)
• EVR breach count — number of times an EVR acceptance threshold was missed, by severity (trending down)
• Design-decision traceability — percentage of material design decisions with a logged trade-off rationale (target: 100%)
• Disclosure freshness — percentage of user-facing disclosures last validated in the current quarter (target: 100%)
• Override utilization — rate of human-override invocation per 1,000 decisions, and resolution time (baseline per system)
• Risk-review cadence compliance — percentage of systems reviewed on the defined cadence (target: 100%)
• Mean time from stakeholder feedback to EVR update — calendar days from feedback intake to accepted EVR change (trending down)

These metrics are produced by the same controls, logs, and registers created during the process itself. No parallel measurement program is required.

Risks if skipped {#risks}

Organizations that publish ethical principles but never run a process like IEEE 7000 expose themselves to five predictable failure modes:

• Principle-to-practice gap. Principles exist in the website’s ethics page but nowhere in the requirements backlog. Engineers cannot implement what is not specified.
• Affected-community blindside. Non-user stakeholders — those most exposed to AI-induced harm — are never consulted, producing systems that optimize for buyers at the expense of those who live with the outputs.
• Un-auditable design rationale. When regulators or litigators ask “how did you weigh privacy against accuracy?” there is no record. The burden shifts from “show the process” to “defend the outcome” — a far weaker posture.
• Reactive ethics. Issues surface through incidents, press, or complaints rather than through design. Remediation is expensive and reputational damage is already done.
• Regulatory surprise. The EU AI Act Article 9 (risk management system) and Article 27 (fundamental-rights impact assessment) expect systematic stakeholder and value analysis. An organization without it scrambles to reconstruct the record retroactively — a reconstruction regulators treat with appropriate skepticism.

Each of these risks carries measurable cost: one avoided incident under GDPR or the EU AI Act typically exceeds the full lifecycle cost of operating IEEE 7000 on a system.

Related standards and references {#references}

• IEEE 7000-2021 — IEEE Standard Model Process for Addressing Ethical Concerns During System Design — standards.ieee.org/ieee/7000/6781/. The source standard; defines the 10 steps and EVR construct.
• IEEE 7000-series — 7001 (transparency), 7002 (privacy), 7003 (algorithmic bias), 7010 (well-being metrics). Companion standards that plug into IEEE 7000 EVRs.
• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system — iso.org/standard/81230.html. Clause 8.2 (system design) is the natural host for IEEE 7000 execution.
• NIST AI Risk Management Framework 1.0 — nist.gov/itl/ai-risk-management-framework. MAP 1.6 (impact characterization) and MAP 5.1 (likelihood and magnitude of impact) are directly fed by IEEE 7000 outputs.
• EU AI Act (Regulation 2024/1689) — eur-lex.europa.eu. Article 9 (risk management), Article 27 (fundamental-rights impact assessment).
• IEEE Ethically Aligned Design, First Edition — standards.ieee.org/industry-connections/ec/ead-v2/. The value-elicitation philosophy that underlies IEEE 7000.
• Friedman, B., Hendry, D. G. (2019). Value Sensitive Design: Shaping Technology with Moral Imagination. MIT Press. The academic lineage of IEEE 7000’s elicitation techniques.

Related COMPEL articles

• AI Ethics Operationalized
• Affected Community Engagement
• ISO 42001 Implementation Using COMPEL
• NIST AI RMF to ISO 42001 Crosswalk

How to cite

COMPEL FlowRidge Team. (2026). “IEEE 7000 Ethical Design Implementation: A 10-Step Value-Based System Design Process.” COMPEL Framework by FlowRidge. https://www.compelframework.org/articles/seo-a2-ieee-7000-ethical-design-implementation/