Effective Date | {effective date} |
SOW # | {sow reference number} |
Customer | {Customer} |
Customer Contact | {Customer Contact Name} {Customer Contact Email} {Customer Contact Phone No} |
Customer Contract Information | |
Ixonn Contact | {Ixonn Contact Name} {Ixonn Contact Email} {Ixonn Contact Phone No} |
Payment Basis | {pre-pay / time-materials / fixed-price} |
Invoice Schedule | {weekly / monthly / other} |
Acceptance | |
Payment Terms | |
Billing Information | |
Subcontractor Information |
1. Description
This Statement of Work (“SOW”) is entered into between Ixonn (“Provider”) and [Customer Name] (“Customer”) for the execution of Ixonn Cybersecurity Services, with the objective to assess, enhance, and/or support the cybersecurity posture of the Customer’s environment based on the agreed scope of work. This Statement of Work (SOW) outlines the scope, deliverables, schedule, and responsibilities associated with the provision of Cybersecurity services, as explicitly defined in the accompanying Appendix and Order Form.
2. Service Scope
The services described in this SOW may include one or more of the following cybersecurity service categories. Items marked as Included will be delivered as part of this engagement. Items marked as Excluded may be proposed separately upon request.:
Item Ref. | Service Item | Service | Included | Excluded |
|---|---|---|---|---|
ICS-01 | Penetration Testing | Simulated cyberattack on networks, applications, APIs, or infrastructure | { ___ } | { ___ } |
ICS-02 | Vulnerability Assessment | Scan and analyse systems for known vulnerabilities | { ___ } | { ___ } |
ICS-03 | Security Risk Assessment | Risk identification and prioritisation for systems and processes | { ___ } | { ___ } |
ICS-04 | Compliance Gap Analysis | Evaluation of compliance posture (e.g., ISO 27001, SOC 2, PCI-DSS) | { ___ } | { ___ } |
ICS-05 | Cloud Security Review | Assessment of cloud architecture (AWS, Azure, GCP) | { ___ } | { ___ } |
ICS-06 | Security Architecture Review | Review and recommendations of existing security designs | { ___ } | { ___ } |
ICS-07 | Incident Response Readiness | Review and/or development of incident response capabilities | { ___ } | { ___ } |
ICS-08 | Phishing Simulation | Simulated phishing campaign to assess user awareness | { ___ } | { ___ } |
ICS-09 | Security Policy Review | Review of organisational security policies and procedures | { ___ } | { ___ } |
ICS-10 | Security Awareness Training | Delivery of training sessions or modules | { ___ } | { ___ } |
3. Service Deliverables
The services described in this SOW may include one or more of the following cybersecurity service categories. Items marked as Included will be delivered as part of this engagement. Items marked as Excluded may be proposed separately upon request.
Item Ref. | Service Item | Deliverable description |
|---|---|---|
ICS-01 | Penetration Testing | Penetration test report, Executive summary, Technical findings, Risk ratings, Recommendations. |
ICS-02 | Vulnerability Assessment | Vulnerability scan report, List of identified vulnerabilities with severity, Remediation guidance. |
ICS-03 | Security Risk Assessment | Summary of key risks, Likelihood and impact matrix, Mitigation roadmap. |
ICS-04 | Compliance Gap Analysis | Compliance checklist, Gaps analysis summary, Required actions. |
ICS-05 | Cloud Security Review | Cloud configuration findings, Control gaps, Secure design recommendations. |
ICS-06 | Security Architecture Review | Analysis of security design and recommendations. |
ICS-07 | Incident Response Readiness | Evaluation of response readiness and proposed improvements. |
ICS-08 | Phishing Simulation | Metrics report, User responses, Follow-up awareness plan. |
ICS-09 | Security Policy Review | Annotated feedback on policies with improvement recommendations. |
ICS-10 | Security Awareness Training | Presentation, Training recordings, Staff surveying. |
4. General Scope Assumptions
4.1. Customer Access and Cooperation:
a) Timely and unrestricted access to necessary personnel, systems, and data
b) Granting of appropriate security clearances and system privileges
c) Provision of required network access
d) Acknowledgment that access delays may impact project timeline
4.2. Customer Project Management:
a) Assignment of dedicated, experienced project manager as primary point of contact
b) Empowerment of project manager to make decisions and allocate resources
c) Coordination of internal stakeholders by Customer project manager
d) Management of organisational change and timely completion of Customer-owned tasks
4.3. Remote Work Execution:
a) Performance of implementation services primarily through remote means
b) Use of secure, industry-standard collaboration and remote access tools
c) Customer’s assurance of network infrastructure compatibility with remote work
d) Mutual agreement required for any on-site work, subject to additional costs
4.4. Customer Hardware and Third-Party Software Responsibilities:
a) Customer’s sole responsibility for procuring necessary hardware and infrastructure
b) Customer’s obligation to obtain and maintain required third-party software licenses
c) Ixonn’s provision of specifications for required components
d) Customer’s accountability for procurement and performance of these elements
5. Customer Obligations
5.1. Dedicated Project Management:
a) Appointment of a dedicated project manager with requisite authority
b) Oversight of all Customer-side aspects of the implementation
c) Internal resource allocation and stakeholder management
d) Primary liaison with Ixonn’s implementation team
5.2. Stakeholder Availability:
a) Ensuring availability of key stakeholders and subject matter experts
b) Participation in crucial project activities (e.g., workshops, reviews, testing)
c) Advance scheduling of key personnel participation
d) Acknowledgment that unavailability may impact project timelines
5.3. Timely Information Provision:
a) Prompt and comprehensive responses to all information requests
b) Provision of detailed business process documentation
c) Sharing of necessary data samples and system access credentials
d) Understanding that delays may affect project milestones
5.4. Deliverable Review and Approval:
a) Timely review and feedback on all project deliverables
b) Adherence to agreed-upon timeframes specified in the project schedule
c) Designation of personnel with authority to approve deliverables
d) Ensuring availability for review sessions and sign-off meetings
6. Schedule
The implementation schedule will be customised based on the specific service offering and Customer requirements. A sample schedule template is provided below:
Item Ref. | Service Item | Duration | Start Date | End Date |
|---|---|---|---|---|
ICS-01 | Penetration Testing | 2 weeks | {TBD} | {TBD} |
ICS-02 | Vulnerability Assessment | 5 business days | {TBD} | {TBD} |
ICS-03 | Security Risk Assessment | 7 business days | {TBD} | {TBD} |
ICS-04 | Compliance Gap Analysis | 5 business days | {TBD} | {TBD} |
ICS-05 | Cloud Security Review | 4 business days | {TBD} | {TBD} |
ICS-06 | Security Architecture | 5 business days | {TBD} | {TBD} |
ICS-07 | Incident Response Readiness | 4 business days | {TBD} | {TBD} |
ICS-08 | Phishing Simulation | 7 business days | {TBD} | {TBD} |
ICS-09 | Security Policy Review | 3 business days | {TBD} | {TBD} |
ICS-10 | Security Awareness Training | 2 business days | {TBD} | {TBD} |
7. Estimated Time and Effort
The professional services fees are based on the selected service scope items and the estimated effort required. A sample fee structure is provided below:
Item Ref. | Service Item | Roles | Hourly Rate | Estimated Hours | Total |
|---|---|---|---|---|---|
ICS-01 | Penetration Testing | Security Analyst QA Reviewer | ${a} ${b} | {y} hours {z} hours 80 hours | ${a*y}+{b*z} |
ICS-02 | Vulnerability Assessment | Security Analyst | ${a} | {y} hours 24 hours | ${a*y} |
ICS-03 | Security Risk Assessment | Risk Assessor Project Manager | ${a} ${b} | {y} hours {z} hours 56 hours | ${a*y}+{b*z} |
ICS-04 | Compliance Gap Analysis | Compliance Analyst | ${a} | {y} hours 40 hours | ${a*y} |
ICS-05 | Cloud Security Review | CloudSecurity Analyst | ${a} | {y} hours 32 hours | ${a*y} |
ICS-06 | Security Architecture | Solution Architect | ${a} | {y} hours 40 hours | ${a*y} |
ICS-07 | Incident Response Readiness | IR Specialist | ${a} | {y} hours 32 hours | ${a*y} |
ICS-08 | Phishing Simulation | Security Analyst Awareness Lead | ${a} ${b} | {y} hours {z} hours 28 hours | ${a*y}+{b*z} |
ICS-09 | Security Policy Review | Governance Analyst | ${a} | {y} hours 16 hours | ${a*y} |
ICS-10 | Security Awareness Training | Content Developer Trainer | ${a} ${b} | {y} hours {z} hours 12 hours | ${a*y}+{b*z} |
Total | ${sum} |
8. Payment Method and Process
8.1. Invoice Issuance:
Ixonn will issue monthly invoices for services rendered, detailing all work performed and expenses incurred. The Customer agrees to promptly review invoices and notify Ixonn of any disputes within 10 days of receipt.
8.2. Payment Terms:
Invoices are payable within 30 days of the invoice date via electronic funds transfer to Ixonn’s designated account. Late payments may incur interest charges as specified in the Master Services Agreement.
8.3. Currency and Taxes:
All fees are quoted in [Currency] and exclude applicable taxes, which are the Customer’s responsibility.
8.4. Payment Method:
Ixonn will provide necessary banking details on each invoice, and the Customer is responsible for ensuring full payment without deductions for transfer fees.
9. Travel and Expenses
9.1. Travel and Expense Approval:
Any travel and expenses incurred by Ixonn personnel in connection with the delivery of services under this SOW will be billed separately from the professional services fees. All such expenses require prior written approval from the Customer. Ixonn will provide an estimate, where possible, of anticipated expenses before any expenses are incurred.
9.2. Expense Billing:
Approved expenses will be billed at cost plus a 10% administrative fee to cover the processing and management of such expenses. Ixonn will provide detailed receipts and documentation for all billed expenses as part of the invoicing process. The Customer has the right to audit these expenses upon reasonable notice.
9.3. Reimbursable Expenses:
The Customer agrees to reimburse reasonable out-of-pocket expenses incurred by Ixonn personnel directly related to the delivery of services under this SOW. All expenses will be in compliance with the Customer’s travel policy, where applicable, provided such policy has been shared with Ixonn in advance.
10. Change Control Process
10.1. Change Request Initiation:
Either party may initiate a request for changes to the scope of work defined in this SOW. All change requests must be submitted in writing using the designated Change Request Form. The requesting party must provide a detailed description of the proposed change, including the rationale for the change and any known or anticipated impacts on the project timeline, resources, or deliverables.
10.2. Impact Assessment:
Upon receipt of a Change Request Form, Ixonn will conduct a thorough assessment of the proposed change. This assessment will evaluate the impact on project scope, schedule, resources, and cost. Ixonn will document the results of this assessment, including any recommendations or alternative approaches, in a Change Impact Analysis document. This analysis will be completed within five (5) business days of receiving the change request, unless otherwise agreed upon by both parties.
10.3. Change Evaluation and Approval:
The Change Impact Analysis will be reviewed by both Ixonn and the Customer. Both parties must mutually agree on the implementation of any change before it can proceed. This agreement includes acceptance of any modifications to project timelines, resource allocations, or additional costs associated with the change. The Customer’s Project Manager and Ixonn’s Project Manager both have the authority to approve changes within predefined limits, while changes exceeding these limits may require higher-level management approval from both organizations.
10.4. Change Documentation:
All approved changes will be formally documented in a Change Order. The Change Order will detail the nature of the change, its impact on the project, any revisions to the project schedule or deliverables, and any associated cost implications. Both parties must sign the Change Order to signify their agreement to the specified changes and their impact on the overall SOW.
10.5. Change Implementation:
Once a Change Order has been fully executed, Ixonn will incorporate the approved changes.
Authorization
This Statement of Work is authorized and agreed to by the undersigned representatives of Ixonn and Customer:
For Customer | For Ixonn |
Name: | Name: |
Title: | Title: |
Signature: | Signature: |
Date: | Date: |
Appendix A – Detailed Phase Descriptions per Service Category
(Applicable to Cybersecurity Services Scope)
All cybersecurity engagements follow a structured service delivery lifecycle to ensure repeatable, auditable, and compliant execution of work. This section provides detailed process descriptions for each scoped service category, aligned to NIST, ISO/IEC 27001, OWASP, CIS Controls, PCI-DSS, and other applicable frameworks.
Each service shall be performed under the principles of confidentiality, integrity, and availability, with a focus on minimising operational disruption, maintaining legal compliance, and preserving client trust.
Disclaimer:
The services provided herein are consultative and advisory in nature. Any findings, recommendations, or reports are based on the information and access granted at the time of engagement. Final implementation, acceptance of risk, and compliance obligations remain the sole responsibility of the Client. [Provider Name] accepts no liability for decisions made based on the interpretation or partial implementation of its recommendations.
ICS-01. Penetration Testing
01-1. Initiation and Planning: A penetration testing engagement is initiated by conducting a formal scoping session to define testing objectives, targets, threat models, risk tolerance, and operational constraints. A Rules of Engagement (ROE) document is produced and signed, outlining permissible actions, notification protocols, escalation paths, and legal boundaries. Scope must explicitly declare in-scope systems, data types, and testing windows.
01-2. Requirements Gathering: Client is required to provide a comprehensive list of target systems (e.g., IP ranges, domains, APIs), access credentials (for authenticated testing), and details of any monitoring systems or rate-limiting infrastructure. Review of past tests and security baselines may be included.
01-3. Execution and Delivery: Testing is conducted using industry frameworks such as OWASP Top 10, MITRE ATT&CK, and NIST SP 800-115. Activities include reconnaissance, enumeration, exploitation, privilege escalation, and post-exploitation techniques. Testing is designed to avoid service disruption unless explicitly authorised.
01-4. Validation and Review: Findings are validated manually to reduce false positives. Risks are contextualised based on exploitability, impact, and business sensitivity. Draft reports undergo peer and technical quality review prior to submission.
01-5. Closure and Handover: A full report is presented including executive summary, technical findings, risk rankings (CVSS), evidence of exploitation, and actionable remediation guidance. A read-out session with stakeholders is conducted.
ICS-02. Vulnerability Assessment
02-1. Initiation and Planning: A non-invasive vulnerability assessment engagement is planned to define scope (internal, external, cloud), credentials required (if authenticated scanning is approved), and scheduling constraints to avoid peak business hours.
02-2. Requirements Gathering: Target systems are identified and approved by the Client. Asset criticality is collected to prioritise results. Where scanning agents or appliances are required, deployment instructions are provided.
02-3. Execution and Delivery: Approved scanning tools (e.g., Nessus, Qualys, OpenVAS) are used in line with the Client’s change control and security monitoring policies. Vulnerabilities are triaged based on CVSS score and asset value.
02-4. Validation and Review: Scan results are filtered to remove known false positives and grouped by severity. Technical details, impacted components, and exposure vectors are included.
02-5. Closure and Handover: A final report is delivered containing an inventory of vulnerabilities, affected hosts, patch and configuration guidance, and risk-ranking methodology.
ICS-03. Security Risk Assessment
03-1. Initiation and Planning: The assessment is launched by identifying business-critical systems, defining risk evaluation methodologies (ISO/IEC 27005, FAIR, or NIST SP 800-30), and assigning roles for participation (e.g., business owner, system custodian).
03-2. Requirements Gathering: Risk data is collected through documentation reviews, stakeholder interviews, and system architecture analysis. Threat actors and environmental risks are profiled.
03-3. Execution and Delivery: Threats, vulnerabilities, and control deficiencies are assessed using a risk matrix (likelihood x impact). Risk treatments (mitigate, transfer, accept, avoid) are proposed per control maturity.
03-4. Validation and Review: Risk ratings are reviewed with asset owners. Alignment to enterprise risk appetite and legal/compliance frameworks is verified.
03-5. Closure and Handover: A risk register is delivered, including all identified risks, responsible owners, recommended mitigation actions, and prioritisation roadmap.
ICS-04. Compliance Gap Analysis
04-1. Initiation and Planning: A framework-aligned compliance audit is defined (e.g., ISO 27001 Annex A, PCI DSS 4.0, SOC 2 Trust Principles, NIST CSF). A compliance owner from the Client is nominated.
04-2. Requirements Gathering: All available policy documents, past audit reports, operational procedures, and evidence of control implementation are reviewed.
04-3. Execution and Delivery: Each clause/control is assessed for presence, effectiveness, and documentation. Maturity scoring may be applied. Gaps are categorised as non-compliant, partially compliant, or compliant.
04-4. Validation and Review: Draft results are validated with compliance owners. Clarifications on evidence or justifications are accepted.
04-5. Closure and Handover: A final compliance gap report is delivered with detailed commentary on each requirement, control maturity level, and a prioritised remediation action list.
ICS-05. Cloud Security Review
05-1. Initiation and Planning: The review focuses on CSP (AWS, Azure, GCP) configurations, IAM policies, and architecture components. Approval for temporary read-only access or CSPM integration may be required.
05-2. Requirements Gathering: Client provides access to cloud console, architectural diagrams, logging configurations, and cloud security tooling outputs (e.g., AWS Trusted Advisor, Microsoft Defender).
05-3. Execution and Delivery: Controls are evaluated against best practice benchmarks such as CIS Benchmarks, AWS Well-Architected Framework, and Azure Security Baseline. Findings include IAM misconfigurations, unencrypted storage, overly permissive roles, and exposed assets.
05-4. Validation and Review: Each misconfiguration is validated against CSP documentation and contextualised with business impact.
05-5. Closure and Handover: A comprehensive security findings report is provided, including screenshots, remediation instructions, and secure design principles.
ICS-06. Security Architecture Review
06-1. Initiation and Planning: The scope includes layers such as network, endpoint, application, identity, and data. Engagement begins with architectural scoping sessions with security architects and engineers.
06-2. Requirements Gathering: Client shares all relevant architecture documentation, access control schemes, threat models, and technology stacks.
06-3. Execution and Delivery: Architecture is reviewed for alignment with Zero Trust, defence-in-depth, and secure-by-design principles. Architectural weaknesses and control gaps are mapped.
06-4. Validation and Review: Proposed improvements are reviewed with architects and technical SMEs. Alternative designs may be explored.
06-5. Closure and Handover: A formal review report is delivered with diagrams, risk commentary, and a roadmap for secure redesign.
ICS-07. Incident Response Readiness Assessment
07-1. Initiation and Planning: The engagement begins with a readiness maturity scoping exercise aligned to NIST 800-61r2 or SANS Incident Response Phases.
07-2. Requirements Gathering: Incident response plans, logs, SOC procedures, case studies, and escalation matrices are reviewed. Tabletop simulation scenarios may be proposed.
07-3. Execution and Delivery: Assessment evaluates detection, containment, eradication, recovery, and post-incident handling. May include tabletop exercise execution with live feedback.
07-4. Validation and Review: IR processes and their gaps are discussed with key stakeholders. Recommendations are validated with IT and legal/compliance teams.
07-5. Closure and Handover: The IR readiness report includes a maturity score, gap analysis, and improvement plan.
ICS-08. Phishing Simulation
08-1. Initiation and Planning: Engagement scope is determined including email templates, audience segmentation, and opt-out groups. Legal review ensures user privacy compliance (e.g., GDPR, CCPA).
08-2. Requirements Gathering: Email lists, organisational hierarchy, and training history are collected. Communications are pre-approved with HR/Legal.
08-3. Execution and Delivery: Controlled phishing emails are sent and user behaviour is tracked (e.g., clicks, data entry, reporting actions).
08-4. Validation and Review: Results are anonymised and analysed. Repeat offenders and departmental trends are identified.
08-5. Closure and Handover: A final report is provided with engagement statistics, risk insights, and training recommendations.
ICS-09. Security Policy Review
09-1. Initiation and Planning: The engagement scope includes review of cybersecurity policies such as Access Control, Data Classification, Acceptable Use, and Password Policy.
09-2. Requirements Gathering: Client provides current policies, version history, enforcement data, and audit findings.
09-3. Execution and Delivery: Each policy is assessed for clarity, coverage, legal adequacy, enforcement mechanisms, and alignment to frameworks (e.g., ISO 27002, NIST 800-53).
09-4. Validation and Review: Findings are shared in annotated format. Policy owners provide clarifications and decide on remediation paths.
09-5. Closure and Handover: Updated policies are delivered with tracked changes, commentary, and governance recommendations.
ICS-10. Security Awareness Training
10-1. Initiation and Planning: Client selects audience groups, preferred delivery format, language, and timing. Training goals (compliance, awareness, behaviour change) are documented.
10-2. Requirements Gathering: Client shares any prior training history, incidents, or focus areas (e.g., phishing, MFA, device use).
10-3. Execution and Delivery: Training content is developed or adapted. Delivery may be live, via LMS, or recorded. All training is evidence-based and scenario-driven.
10-4. Validation and Review: Feedback is collected. Knowledge retention is assessed through quizzes or post-training surveys.
10-5. Closure and Handover: Training materials, attendance logs, and feedback summaries are provided with suggestions for program improvement.
