CYBERSECURITY UNDER PRESSURE TECHNICAL CONTRIBUTION TEMPLATE Thank you for considering a contribution to Cybersecurity Under Pressure. Please complete this short template before preparing a full draft. It helps us understand the technical idea first, so neither side needs to invest time in a complete article before we know it is a good fit. Fields marked REQUIRED are needed for the initial editorial review. ============================================================ A. PROPOSAL ============================================================ Working title: [REQUIRED] Claim under review: [REQUIRED] State in 1–2 sentences exactly what the contribution intends to demonstrate. A topic is not a claim; the aim is to make the technical proposition clear. Why this matters to the Cybersecurity Under Pressure audience: [REQUIRED] Primary sector(s): [REQUIRED] [ ] OT / ICS [ ] Automotive [ ] Railway [ ] Product Security [ ] Software Supply Chain [ ] Critical Infrastructure [ ] Other: __________________________ ============================================================ 1. ARCHITECTURE & TRUST CONTEXT ============================================================ System / subsystem / operational process: [REQUIRED] Trust boundaries: [REQUIRED] Identify where trust changes between components, organisations, networks, suppliers or operational roles. Relevant interfaces, protocols or data paths: [REQUIRED] Operational or safety dependency: [REQUIRED] Threat, failure or misuse scenario under analysis: [REQUIRED] Architecture evidence available: Examples: diagram, interface specification, data-flow description, protocol documentation, public technical record. ============================================================ 2. ENGINEERING CONSTRAINT OR REGULATORY FRICTION ============================================================ Technical or architectural constraint: [REQUIRED] Safety / availability / latency / lifecycle constraint: [REQUIRED] Relevant regulation, standard or assurance requirement: [REQUIRED] Include exact references where possible. Supplier / ownership / integration boundary: [REQUIRED] Why the straightforward mitigation may be insufficient: [REQUIRED] Explain the real engineering friction rather than simply naming a recommended control. ============================================================ 3. DECISION, TRADE-OFFS & EVIDENCE ============================================================ Alternatives evaluated: [REQUIRED] Selected design or assurance approach: [REQUIRED] Engineering trade-offs: [REQUIRED] Residual risk: [REQUIRED] Evidence supporting the decision: [REQUIRED] Examples: TARA outputs, architecture review, SBOM/VEX artefacts, penetration-test results, fault-injection results, verification records, logs, standards clauses, incident records or primary technical research. Primary sources: [REQUIRED] For each source provide title, publisher/owner, date where available, and direct URL or document reference. ============================================================ B. AUTHOR & CONFLICT-OF-INTEREST DECLARATION ============================================================ Author name: [REQUIRED] Role / technical background: [REQUIRED] Organisation: [OPTIONAL] Relevant employment, commercial or financial relationship with the subject of this proposal: [REQUIRED] Write NONE if there is no relevant relationship. A disclosed relationship does not automatically exclude a contribution; transparency is what matters. Has any vendor, employer or client reviewed, commissioned, funded or requested this contribution? [REQUIRED] [ ] No [ ] Yes — explain: _________________________________________ ============================================================ C. EDITORIAL INDEPENDENCE CHECK ============================================================ Please confirm each statement before submitting: [ ] The proposal is intended as technical analysis, not promotion of a cybersecurity product or service. [ ] It contains no sales language, lead-generation links or calls to contact a vendor. [ ] It is not primarily a demonstration of a commercial tool. [ ] Material factual claims can be supported by attributable evidence. [ ] All three technical blocks are complete. [ ] Any commercial product named is technically necessary to identify the affected system, vulnerability or evidence, rather than to market it. ============================================================ SUBMISSION ============================================================ Send the completed template to: contact@cybersecurityunderpressure.com Suggested email subject: Technical Contribution Proposal — [Working title] Please start with this template rather than a full article. If the proposal looks like a good fit, we will invite you to develop the full draft for review.