Before bidding for your first ECSS-governed contract, identify the customer’s applicable documents, exact editions, technical scope and required deliverables. Turn each obligation into engineering work, evidence and an accountable owner. Resolve unclear applicability or acceptance assumptions before committing to price and schedule. The result should be a defensible bid position, not an unexplained promise to comply with every ECSS document.
ECSS is the European Cooperation for Space Standardization. Its system description explains application through the customer–supplier chain. The current system page identifies ECSS-S-ST-00C Rev.2, dated 21 November 2025, and notes that tailoring is addressed in a separate document. Your project’s invoked editions and agreements remain the starting point. ECSS-S-ST-00C Rev.2: ECSS system
Which tender inputs should we fix first?
Collect the statement of work, technical specification, applicable-document list, deliverable list, proposed agreement and clarification responses. Record each version and the precedence rules stated in the package. Where references conflict, ask the customer for clarification; do not resolve the commercial commitment by choosing the easier document.
Use the applicability and tailoring guide to distinguish source requirements from project decisions. A requirements export can help organise the source, but it does not decide which edition or clause governs your product. Keep the customer’s accepted decision and its rationale alongside the reference.
What work supports the supplier’s obligations?
Fictional example: a mechanism supplier is asked to deliver a representative actuator and verification records. The customer’s package invokes a verification standard but leaves the test model and facility responsibilities unclear. The table is an internal bid worksheet, not an ECSS-mandated template or a completed compliance assessment.
| Input / obligation | Work to estimate | Clarification and accountable role |
|---|---|---|
| Invoked verification requirements | Plan methods, evidence records, review and closure activities for the actuator scope | Verification lead confirms applicable edition and required deliverables. |
| Model and configuration | Define the supplied item, representative features and controlled configuration list | Chief engineer asks which differences from the flight design are acceptable. |
| Environmental test campaign | Estimate facility access, fixtures, instrumentation, procedure, analysis and anomaly work | Test lead confirms who provides the facility and host conditions. |
| Evidence handover | Prepare report, raw-data references, configuration identification and unresolved-item status | Project lead agrees handover format and customer acceptance authority. |
ECSS-E-ST-10-02C Rev.1 is a published verification standard. Whether its particular requirements and deliverables apply to this supplier must be established through the project. ECSS-E-ST-10-02C Rev.1: Verification Do not turn the example above into a blanket claim that every grant applicant must submit a specific ECSS document.
How do we turn gaps into a bid decision?
For each unresolved point, record the assumed answer, effect on cost or schedule, person responsible for clarification and latest decision date. If the host environment is unknown, the supplier may be able to estimate interface definition work but cannot confidently price a complete environmental campaign. State that dependency in the bid through the mechanism the tender permits.
Distinguish a proposed tailoring decision from a supplier nonconformance or a plan to fulfil a requirement. “Not applicable” needs a reason and the required agreement. “Will comply” needs funded tasks and evidence. “Exception requested” needs an explicit decision. The compliance matrix guide explains how to keep these records interpretable.
What changes when funding comes first?
A funding criterion and a customer’s contractual requirement are different sources of obligation. A grant proposal can describe an intended verification approach without claiming the final customer has accepted every detail. As a customer or prime becomes involved, identify what needs to flow into the supplier agreement, who owns the interface and which evidence will be handed over.
Use the UK funding and contracting hub to select the route and the consortium supplier checklist to define handover boundaries. The shared workbook includes an obligations sheet for source, applicability question, effort and owner; retain your customer’s required formats for the formal response.
What should the pre-bid review decide?
The bid owner should be able to explain what the team is committing to, which assumptions remain and how they affect delivery. The engineering authority should be able to trace each material technical promise to planned work and a reviewable evidence output. Review effort for corrections and rework as well as the first test run. Keep the agreed source versions with the bid so a later customer change can be assessed against the commitment actually made.
Carry pre-bid clarifications into the programme
Connect each actuator obligation to its source, proposed verification work, deliverable and unresolved customer question. Preserve the clarification decision alongside the requirement so the delivery team can see the basis of the accepted scope. Arc’s connected programme model can organise that context; engineers retain the technical and approval decisions.
Frequently asked questions
Does every ECSS standard apply to my bid?
Establish the standards and requirements invoked by the actual project agreement and their applicability to your work. Do not assume the entire ECSS collection applies in full to every supplier.
Can I use the newest ECSS edition instead of the tender’s edition?
Record the edition specified by the customer. If you propose another edition, raise it as a clarification or proposed change and obtain the required agreement rather than substituting it silently.
Does completing an ECSS checklist demonstrate compliance?
No. The checklist organises obligations, work, evidence and unresolved decisions. Fulfilment depends on the agreed requirements, engineering evidence and the customer’s acceptance process.
Connect one bid commitment to its engineering evidence.
Try a work package in Arc: organise its requirements, interfaces, risks, verification work and evidence so your team can review the next decision.