Technology and Third-Party Service Approval Procedure

Organization: Igzibo Engineering Solutions, Inc.
Version: 1.0
Status: Living procedure
Effective Date: September 16, 2026
Owner: Igzibo Engineering Solutions, Inc.
Review Cycle: At least annually and after material changes to technology governance, procurement practices, security requirements, client requirements, or applicable law.

1. Purpose

This procedure establishes the operational process for evaluating, approving, implementing, reviewing, renewing, and retiring technology products and third-party services used for Igzibo business.

The procedure implements the requirements of the Technology and Third-Party Service Security Standard and provides a documented approval path before material technology or third-party services are adopted.

2. Scope

This procedure applies to technology products and third-party services used for organizational business, including:

• Software and Software as a Service (SaaS).
• Cloud services.
• Infrastructure and hosted platforms.
• Business applications.
• Developer tools.
• Browser extensions and plugins.
• Artificial Intelligence (AI) services.
• Integrations and applications requesting organizational access.
• Managed technology services.
• Technology providers and service providers.
• Free trials and free services when used for organizational purposes.

It applies whether a service is purchased, provided at no monetary cost, supplied by a client, or otherwise made available for business use.

Definitions

• AI: Artificial Intelligence, technology that performs tasks commonly associated with human intelligence.
• Approval: Documented authorization to adopt or use a technology product or third-party service for an identified business purpose.
• Approver: The person authorized to approve a technology product or third-party service based on its risk and business impact.
• Due Diligence: Reasonable investigation performed before entering into or materially expanding a relationship with a technology provider.
• Igzibo: Igzibo Engineering Solutions, Inc.
• Service Owner: The person responsible for the business purpose, configuration, access, security coordination, and continued need for a technology service.
• Third Party: An organization or individual outside Igzibo that provides technology, services, access, data processing, or other capabilities to Igzibo.
• Technology Service: A software, hardware, cloud, hosted, managed, or technology-enabled product or service used for business purposes.
• Security Review: A documented evaluation of a product or service's security, privacy, access, data, and operational risks.

4. Core Requirements

Technology and third-party services must not be adopted for material business use without appropriate review and approval.

The level of review must be proportionate to:

• Information sensitivity.
• Requested permissions.
• Business criticality.
• Security risk.
• Privacy risk.
• Client requirements.
• Regulatory or contractual requirements.
• Integration complexity.
• Provider dependency.
• Operational impact.

Approval of a service does not authorize uses that are prohibited by another Igzibo policy, standard, procedure, client requirement, contract, or applicable law.

5. Request Initiation

A requester seeking to adopt a technology product or third-party service should provide, as applicable:

• Product or service name.
• Provider name.
• Business purpose.
• Proposed users.
• Information to be processed.
• Requested permissions.
• Systems or integrations involved.
• Client information involved.
• Expected cost or commercial terms.
• Expected duration.
• Business criticality.
• Known contractual or client requirements.
• Proposed Service Owner.

Requests should be submitted through the designated Igzibo technology approval mechanism.

6. Initial Screening

The Service Owner or designated reviewer should determine whether the request:

• Has a legitimate business purpose.
• Uses an organizational account where practical.
• Involves organizational or client information.
• Requires access to organizational systems.
• Creates a material security or privacy risk.
• Requires contractual review.
• Requires client approval.
• Requires enhanced review because of its risk or criticality.

Low-risk services may use a simplified review when appropriate. Moderate-, high-, and critical-risk services require progressively stronger review.

7. Information and Access Review

Before approval, determine:

• What information the service collects or processes.
• Where information is stored.
• Who can access the information.
• Whether information is transmitted to third parties or subprocessors.
• How long information is retained.
• Whether information is used for provider training or product improvement.
• Whether information can be exported.
• Whether information can be deleted.
• What happens to information when the relationship ends.
• What permissions the service requests.
• Whether permissions can be limited.
• Whether persistent credentials or tokens are created.
• Whether access can be revoked.

Information handling must comply with the Data Classification and Handling Standard and, when client information is involved, the Client Data Processing Standard and applicable client requirements.

8. Security Review

Where appropriate, the review should consider:

• Authentication and Multi-Factor Authentication (MFA).
• Administrative access controls.
• Encryption.
• Logging and monitoring.
• Vulnerability management.
• Security testing.
• Incident response.
• Security documentation.
• Independent security assessments or certifications.
• Provider security history.
• Material public security incidents.
• Data-location considerations.
• Subcontractors and subprocessors.
• Business continuity and recovery capabilities.

The Technology and Third-Party Service Security Standard establishes the substantive security requirements.

9. Privacy Review

When personal information is involved, consider:

• Purpose of collection and processing.
• Categories of personal information.
• Data minimization.
• Retention.
• Deletion.
• Access and correction mechanisms.
• International processing.
• Provider and subprocessor access.
• Contractual privacy protections.
• Applicable privacy notices.
• Applicable legal or regulatory requirements.

The review should coordinate with the applicable Privacy Notice, Employee and Contractor Privacy Notice, Candidate and Applicant Privacy Notice, and Cookie and Tracking Notice where relevant.

10. Client and Contractual Review

Before using a technology or third-party service for client information, review applicable client contracts, Statements of Work (SOWs), security requirements, and other binding requirements.

Client restrictions may address:

• Cloud providers.
• AI services.
• Data locations.
• Subcontractors.
• Public repositories.
• Specific software.
• Integrations.
• Data retention or deletion.

Igzibo approval does not override a client-specific restriction.

11. AI Services

AI services require review under this procedure and the AI and Generative AI Usage Standard.

Before approving an AI service for business or client information, consider:

• Data retention.
• Model-improvement practices.
• Human access.
• Security controls.
• Account ownership.
• Deletion.
• Export.
• Subprocessors.
• Integration permissions.
• Client restrictions.
• Whether the service can take actions through connected systems.

AI services capable of taking actions through connected tools require heightened review.

12. Third-Party Integrations and Delegated Access

Integrations that request access to organizational accounts or systems must be reviewed before authorization.

The reviewer should determine:

• Information the integration can access.
• Actions it can perform.
• Whether access can be limited.
• Whether persistent tokens are created.
• Whether access can be revoked.
• Whether permissions exceed the immediate business purpose.

Broad access to email, cloud storage, source repositories, financial information, or administrative functions requires heightened review.

13. Contract and Commercial Review

For higher-risk or material services, the review should determine whether written contractual terms are appropriate.

Where applicable, agreements should address:

• Confidentiality.
• Data ownership.
• Data processing.
• Security requirements.
• Incident notification.
• Breach response.
• Subcontractors.
• Data location.
• Data retention.
• Data deletion.
• Data export.
• Availability.
• Support.
• Termination.
• Transition assistance.
• Assurance or audit information.

A Data Processing Agreement (DPA) should be considered when a provider processes personal information on behalf of Igzibo or a client.

A Service Level Agreement (SLA) should be considered when availability or response times are material to operations.

14. Approval Decision

The review outcome should be documented as one of:

• Approved.
• Approved with conditions.
• Deferred pending additional information or controls.
• Rejected.

The approval record should identify:

• Service.
• Provider.
• Business purpose.
• Service Owner.
• Review date.
• Risk level where assigned.
• Information involved.
• Key permissions.
• Required conditions.
• Approver.
• Approval date.
• Review or expiration date where applicable.

Approval conditions must be implemented before the service is used in a manner covered by those conditions.

15. Implementation

After approval:

• Create or configure the service using organizational ownership where practical.
• Apply required security settings.
• Use least-privilege permissions.
• Enable MFA where available and appropriate.
• Configure logging where supported.
• Document material integrations.
• Record ownership and recovery information.
• Apply data-handling requirements.
• Complete required contractual steps.
• Confirm client approval when required.

Users must not bypass required approval by creating personal accounts or using an unapproved equivalent service.

16. Review and Monitoring

Approved services should be reviewed according to risk and business need.

Review triggers include:

• Material security incident.
• Material change in provider.
• Significant change in service capabilities.
• New data or permissions.
• Material client requirement change.
• Contract renewal.
• Significant pricing or commercial change.
• Major technology integration.
• Significant supply-chain risk.
• End of business need.

Unused or unnecessary services and integrations should be removed.

17. Renewal

Before renewing a material service, the Service Owner should confirm:

• The business need remains valid.
• The service remains appropriate for the information processed.
• Required security controls remain adequate.
• Client requirements remain satisfied.
• Contractual terms remain appropriate.
• The provider has not introduced material unacceptable changes.
• Ownership and access remain current.

Renewal should be documented according to the applicable approval level.

18. Exceptions

Exceptions require documented authorization and must identify:

• Service and affected control.
• Business justification.
• Security and privacy risk.
• Compensating controls.
• Responsible owner.
• Approval authority.
• Review or expiration date.

Exceptions must not authorize conduct prohibited by law or binding contractual requirements.

19. Service Retirement

When a service is no longer required:

• Access should be removed.
• Integrations should be disabled.
• Credentials and tokens should be revoked or rotated as appropriate.
• Organizational data should be exported, returned, or deleted according to requirements.
• Client information should be handled according to client instructions.
• Records should be retained or disposed of according to the Records Retention and Disposal Standard.
• Accounts and subscriptions should be closed where appropriate.
• Ownership and documentation should be updated.

20. Roles and Responsibilities

Requester

The requester provides accurate business and technical information needed for review and follows approval conditions.

Service Owner

The Service Owner is responsible for the business need, ongoing ownership, access, review, and retirement of the service.

Security or Technology Reviewer

The reviewer evaluates security, privacy, access, integration, and operational risks appropriate to the service.

Contract or Procurement Owner

Where applicable, the contract or procurement owner ensures that material commercial, security, privacy, and data requirements are addressed.

Approver

The approver confirms that the review is sufficient for the service's risk and business purpose and records the approval decision.

21. Records

Approval records, security reviews, contracts, conditions, exceptions, renewal decisions, and retirement records should be retained according to the Records Retention and Disposal Standard.

22. Enforcement

Failure to follow this procedure may result in removal of unauthorized services, access restrictions, corrective action, contractual remedies, or other appropriate action.

23. Relationship to Other Governance Documents

This procedure implements and complements:

1. Technology and Third-Party Service Security Standard.
2. Technology Acceptable Use Policy.
3. Identity and Access Management Standard.
4. Password and Authentication Standard.
5. Data Classification and Handling Standard.
6. AI and Generative AI Usage Standard.
7. Client Data Processing Standard.
8. Records Retention and Disposal Standard.
9. Backup and Business Continuity Standard.
10. Security Incident Response Procedure.
11. Employee and Contractor Offboarding Procedure.

24. References and Research Basis

This procedure operationalizes the existing Technology and Third-Party Service Security Standard, which requires risk-based evaluation, provider review, data review, integration review, contractual consideration, lifecycle governance, and service retirement.

Version History