Summary

  • On 6 September, ICANN’s Board authorized the President and CEO, or his designees, to contract with a preferred vendor for Engineering & IT staff-augmentation services. The resolution was published on 9 September.
  • ICANN says the arrangement can supply software engineering, quality assurance, content-management and other technical skills, scale with changing priorities, and extend operational coverage across time zones.
  • ICANN’s own delegation guidelines say authority and responsibility can be delegated but accountability cannot. Its contracting policy likewise separates signing a contract from retaining approval responsibility.
  • The public decision does not identify a role-level authority map. A bounded role-control receipt could show the internal owner, external function, privilege class, approval boundary and offboarding evidence without exposing people or sensitive systems.

The Board approved elasticity

The approved resolutions from 6 September 2026 give the President and CEO, or his designees, authority to enter a contract with the preferred vendor and make related disbursements. The object is described as Engineering & IT strategic staff augmentation. The page was published three days after the meeting.

The rationale is unusually clear about the operating case. ICANN combines internal technical capability with targeted outside expertise. It wants to expand or contract capacity as priorities change, obtain skills that may not justify permanent posts, cover more time zones, respond to concurrent projects and align external cost with demand. The named functions include software engineering, quality assurance and content management. The support reaches strategic initiatives and ongoing operational services.

Those are descriptions of capacity. They do not, by themselves, assign institutional authority. A developer can prepare a change without approving it. A quality-assurance specialist can reject a build under a test plan without deciding ICANN policy. A content specialist can execute a publication step without owning the decision to publish. An on-call engineer may restore service under a runbook while an ICANN officer remains accountable for the operating framework.

The resolution does not say the opposite. It simply does not publish this functional map. Negotiating particulars are redacted, and the open page does not establish the vendor, price, term, signature date, headcount, locations or current execution state. No responsible reading should fill those blanks with suspicion or guesswork.

ICANN already has an accountability grammar

The strongest standard comes from ICANN itself. Its Delegation of Authority Guidelines, amended in October 2024, say that authority and responsibility can be delegated but accountability cannot. The Board remains accountable for its Bylaws powers. Where authority rests with the President and CEO, other people in the organization may lead work, but responsibility remains with the President and CEO.

The same document assigns day-to-day operations to the President and CEO and says Board resolutions must be implemented within the scope of the delegated authority they contain. The Board oversees the CEO; the CEO is the day-to-day decision maker. This is not a ban on distributing work. It is a demand that a chain of work never become a chain without an owner.

ICANN’s Contracting and Disbursement Policy, effective since January, makes the distinction concrete. It sets financial approval levels and normally reserves obligations above US$750,000 for the Board, subject to its rule for specifically approved project budgets. An officer may delegate contract-signing authority in writing, with the class of commitment specified and legal approval recorded. But the policy states that approval authority is not delegated and the officer remains ultimately responsible.

That is the useful analogy for augmented engineering. A signature can travel farther than approval. Execution can travel farther than accountability. The public evidence should preserve those separations at the point where outside personnel enter a workstream.

The blended workforce is not new

The Board minutes from 3 May 2025 place the current decision in a longer operating history. They say ICANN first engaged an expert third-party outsourcing firm to augment IT capacity in 2014, selected a provider through RFP processes in 2014 and 2017, and then made consecutive renewals through May 2025. That record says the then-current firm had supplied development, quality-assurance and content-management support.

History does not identify the 2026 counterparty. The new resolution uses “preferred vendor,” but the public evidence does not prove that it is the same supplier, a renewal or a replacement. It does show that external technical capacity is not an emergency improvisation. It is a durable component of ICANN’s operating model.

ICANN’s FY25 Form 990 gives scale without describing the new contract. It reports 136 independent contractors paid more than US$100,000 in the relevant period, and several of the highest-paid suppliers are described as providing IT consulting services. The filing also says regional people totals include directly employed staff, people seconded through a third-party employer and long-term independent contractors.

The filing says written conflict-of-interest policies apply to independent contractors and that annual disclosure statements are completed. ICANN’s public employee-practices page separately describes confidentiality and conflict duties for staff. These records are positive evidence of controls. They are not a public statement of which 2026 external role can touch which class of system, prepare which decision, approve which action or retain which evidence after leaving.

Publish the control classes, not the attack surface

A useful public record need not list individual contractors, hostnames, credentials, vulnerabilities or live incident procedures. Those disclosures could create privacy and security risks. The right level is a role-control receipt tied to resolutions 2026.09.06.03–.04 and, once executed, to a stable contract identifier.

For each workstream, the receipt could name the accountable ICANN officer and the internal operational owner. It could describe the external function as a class, identify the system or data classification and privilege tier, and state whether the role may prepare, execute, recommend or approve a material action. It could record segregation-of-duty rules, escalation paths, whether subcontracting is permitted, and the status of conflict and confidentiality attestations.

The end of the engagement belongs in the same record. A start date without an end condition is only half a permission. The receipt could show review and expiry dates, access-revocation attestation, custody of code and operational evidence, and correction history. None of that requires publishing the person behind an account or the technical detail that would help an attacker.

This is Daniel Kade’s editorial model, not an ICANN requirement or a description of an existing public system. The present source set does not show that access is excessive, approvals are confused or offboarding is weak. It shows that the Board has explained the capacity it wants without publishing the interface that keeps that capacity subordinate to accountable authority.

This is not the redaction question

The companion resolution keeps negotiating information confidential until the President and CEO decides it may be released. Vendor, price and term could later improve procurement transparency. They would not answer the authority question. A named supplier can still operate under a vague public responsibility boundary; an unnamed supplier can be governed internally by precise controls.

The Governance Guidelines assign the Board oversight of management performance, enterprise risk and sound information-technology planning. The governance-document index makes ICANN’s high-level allocation of authority easy to find. The missing connector is narrower: a public, non-sensitive projection from that institutional map into a durable blended workforce.

ICANN classifies the contract authorization as an Organizational Administrative Function that does not require public comment. A role receipt would not convert personnel management into a referendum. It would make the organization’s own doctrine observable: capacity may move across an organizational boundary; accountability does not disappear with it.

Sources