Key Dimensions and Scopes of Technology Services

The technology services sector in the United States operates across a fragmented landscape of service categories, delivery models, regulatory regimes, and contractual boundaries — each with distinct scope definitions that determine what a provider does, what qualifies as in-scope work, and where professional or legal accountability begins and ends. Information architecture (IA) services sit within this landscape as a specialized discipline governing how digital information is structured, labeled, and made navigable across platforms and organizations. Scope disagreements between clients and providers are among the most frequent sources of contract disputes, project failures, and compliance gaps in technology engagements. The dimensions covered here span regulatory, geographic, operational, and contextual factors that together define the boundaries of technology service delivery.

• What falls outside the scope
• Geographic and jurisdictional dimensions
• Scale and operational range
• Regulatory dimensions
• Dimensions that vary by context
• Service delivery boundaries
• How scope is determined
• Common scope disputes

What falls outside the scope

Technology services scope exclusions are not uniform across the sector — they depend on service category, client type, regulatory regime, and contractual specifics. However, structural exclusions recur consistently across engagements.

Information architecture services do not encompass software development, application engineering, database administration, or infrastructure provisioning. An IA engagement that produces a site map, taxonomy, or content model does not extend to the technical implementation of those structures unless a separate statement of work explicitly includes it. The distinction between IA deliverables and engineering execution is addressed in the IA-UX relationship context, where designers, architects, and engineers operate in adjacent but non-overlapping responsibility zones.

Cybersecurity services — including penetration testing, security operations center (SOC) functions, and identity and access management (IAM) — fall outside the scope of IA engagements even when the subject matter overlaps. Metadata tagging of security-sensitive content, for instance, is an IA function; the security classification decisions governing that content are not.

Legal and compliance advisory services are outside scope for technology service providers unless the provider holds specific licensure. Technology firms may surface regulatory requirements relevant to a project (such as Section 508 accessibility standards or HIPAA data handling rules), but the legal interpretation of those requirements requires licensed counsel.

Outside-scope categories also include:

• Hardware procurement and physical infrastructure
• End-user training programs (distinct from documentation architecture)
• Content creation and editorial production (distinct from content modeling)
• Business process reengineering beyond information-flow analysis

Geographic and jurisdictional dimensions

Technology service providers operating nationally in the United States encounter a layered jurisdictional structure that affects licensing, data handling, accessibility requirements, and contractual enforceability.

At the federal level, agencies contracting for technology services must comply with the Federal Acquisition Regulation (FAR), which governs procurement scope, performance standards, and contractor qualifications. IA services delivered to federal clients are subject to Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), administered by the U.S. Access Board, which mandates accessibility standards for electronic and information technology. The IA accessibility obligations for federal and federally funded projects are non-negotiable scope items regardless of how a contract is worded.

At the state level, 50 separate procurement frameworks govern technology service contracting with state agencies. California's Department of General Services maintains IT procurement policies distinct from Texas's Department of Information Resources (DIR), which manages a cooperative contracts program covering over 600 active technology vendors. State data privacy laws — including the California Consumer Privacy Act (CCPA) and Virginia's Consumer Data Protection Act (CDPA) — create additional scope constraints for IA work involving personal data structuring, search architecture, or metadata frameworks.

International jurisdiction becomes relevant when US-based providers deliver services to multinational clients or when cloud infrastructure spans jurisdictions. The European Union's General Data Protection Regulation (GDPR) imposes specific requirements on data structure and retention that directly affect metadata framework design and content inventory processes.

Geographic scope also determines which professional certification bodies carry authority. The Information Architecture Institute (IAI) and the American Institute of Certified Planners (AICP) — while operating nationally — do not confer licensure in the regulatory sense. Technology service scope defined by geography must therefore distinguish between regulatory jurisdiction and professional community standards.

Scale and operational range

Technology services span a range from single-project consulting engagements to enterprise-wide managed service agreements. The operational scale of an engagement determines the governance structures, staffing models, delivery timelines, and audit requirements that apply.

The IA scalability dimension is particularly significant at enterprise and managed-service scale, where taxonomy drift, governance gaps, and undocumented classification decisions compound over time. ITIL 4, published by AXELOS (now PeopleCert), provides a framework for IT service management that defines scope boundaries across service strategy, design, transition, operation, and continual improvement — each phase carrying distinct IA implications.

Regulatory dimensions

The regulatory environment for technology services in the United States is sector-specific rather than unified. No single federal agency regulates "technology services" as a category; instead, industry-specific regulators impose technology standards within their domains.

Healthcare technology services fall under the Health Insurance Portability and Accountability Act (HIPAA), enforced by the HHS Office for Civil Rights. The HIPAA Security Rule (45 CFR Part 164) sets technical safeguard requirements that directly constrain knowledge management IA and search systems architecture in covered entity environments. Violations carry civil monetary penalties up to $1.9 million per violation category per year (HHS Civil Monetary Penalties).

Financial services technology is regulated by the Office of the Comptroller of the Currency (OCC), the Federal Reserve, and the Securities and Exchange Commission (SEC), depending on institution type. The SEC's Regulation S-P governs information security programs for broker-dealers and investment advisers, with direct implications for how information architectures handling client data are structured.

Federal information systems must comply with the Federal Information Security Modernization Act (FISMA), which references NIST standards — particularly NIST SP 800-53 (Security and Privacy Controls) and NIST SP 800-60 (Mapping Information Types to Security Categories). These standards define how federal agencies must categorize, label, and control access to information, creating a regulatory floor for IA for cloud services and SaaS platforms serving government clients.

Accessibility regulation applies across sectors. The Web Content Accessibility Guidelines (WCAG) 2.1, published by the World Wide Web Consortium (W3C), are referenced by Section 508 and form the technical standard against which labeling systems and navigation systems are evaluated in regulated environments.

Dimensions that vary by context

Scope in technology services is not static — it shifts based on client type, delivery model, platform environment, and maturity of the client organization.

Client type alters scope in measurable ways. A federal agency engagement requires compliance documentation, security categorization, and 508 testing that a commercial client engagement does not. A startup client may lack the internal governance structures needed to sustain an IA governance framework, requiring the provider to include governance design as an in-scope deliverable rather than a client-owned function.

Platform environment determines which IA components are technically feasible. A faceted classification system that functions well on an enterprise search platform (such as Elasticsearch or Microsoft SharePoint) may be structurally incompatible with a legacy content management system lacking facet-rendering capabilities. The IA tools and software environment must be assessed before scope is fixed.

Organizational maturity — measurable using the IA maturity model — determines the starting baseline for any engagement. An organization operating at maturity level 1 (ad hoc, undocumented information practices) requires foundational audit work before taxonomy or ontology development can begin. An organization at maturity level 4 (managed, metrics-driven) may scope an engagement entirely around optimization and findability measurement.

Delivery model (staff augmentation, managed service, project-based consulting, embedded team) defines accountability boundaries, which in turn define scope. Staff augmentation agreements typically make the client organization responsible for direction and scope expansion; managed service agreements typically assign the provider responsibility for identifying and flagging scope changes.

Service delivery boundaries

Service delivery boundaries define the handoff points between a technology service provider's responsibilities and those of the client organization or third-party vendors.

Deliverable boundaries specify what format and completeness standard constitutes a completed work product. An IA audit deliverable may be scoped as a findings report, a prioritized remediation backlog, or both — and the boundary between those two outputs is contractually significant. Similarly, a card sorting study or tree testing study may be scoped to include recruitment, facilitation, analysis, and recommendations, or only a subset of those phases.

Integration boundaries define where IA deliverables connect to engineering systems. API documentation architecture services, for instance, produce structured content models and navigation hierarchies — but the integration of those structures into a developer portal is typically an engineering function outside the IA provider's scope unless explicitly contracted.

Support and maintenance boundaries determine what happens after initial delivery. IA deliverables — taxonomies, ontologies, wireframes, content models — require periodic review as organizational content and user needs evolve. Whether ongoing maintenance is in scope or requires a separate retainer is a recurring source of post-project disputes.

The cross-channel IA context introduces additional boundary complexity: a taxonomy developed for a web platform may not automatically apply to a mobile application, voice interface, or physical wayfinding system. Each channel may constitute a separate scope of work.

How scope is determined

Scope determination in technology service engagements follows a structured sequence of activities, each of which produces artifacts that constrain subsequent decisions.

Scope determination sequence:

1. Discovery phase — stakeholder interviews, existing system audit, identification of authoritative content sources and user populations
2. Requirements documentation — functional requirements (what the system must do), non-functional requirements (performance, accessibility, security), and constraint documentation (platform, budget, timeline)
3. Scope statement drafting — explicit enumeration of in-scope deliverables, out-of-scope exclusions, and assumptions
4. Standards alignment — mapping deliverables to applicable standards (WCAG, NIST, HIPAA technical safeguards, FAR clauses)
5. Change control protocol definition — process for identifying, documenting, and pricing scope changes during execution

The IA standards and best practices framework provides reference criteria for what constitutes a complete and professionally defensible scope statement in information architecture engagements. The broader technology service context for scope determination is addressed across the Information Architecture Authority index, which covers how these dimensions interact across service categories.

Common scope disputes

Scope disputes in technology services cluster around a predictable set of boundary conditions that recur regardless of project type or client sector.

Dispute type 1: Taxonomy maintenance vs. taxonomy design. Clients frequently assume that a delivered taxonomy will require no ongoing adjustment. Providers assume maintenance is a separate engagement. Without explicit language, both assumptions create legitimate contractual claims.

Dispute type 2: User research inclusion. Whether user research for IA — including card sorting, interviews, and usability testing — is included in an IA design engagement or treated as a prerequisite the client must supply is a persistent ambiguity. ANSI/INCITS standards for usability testing define minimum sample sizes and protocols, but do not resolve contractual scope questions.

Dispute type 3: Accessibility compliance vs. accessibility design. Providers may scope IA accessibility as designing accessible structures; clients may expect that scope to include remediation of accessibility failures discovered post-launch. Section 508 compliance obligations run to the procuring agency, not solely to the contractor.

Dispute type 4: Digital transformation IA scope creep. In digital transformation engagements, IA scope frequently expands as undocumented legacy systems are discovered. Without a documented change control process, the discovery of a 40,000-document legacy intranet mid-engagement can double effective scope with no corresponding contract adjustment.

Dispute type 5: Ontology development vs. content population. Ontology and controlled vocabulary development is a structural IA function; populating a taxonomy with actual content tags is a content operations function. The two are adjacent but distinct, and confusion between them generates both billing disputes and timeline failures.

Reference comparison: Scope dispute types by service category