Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
EDI and E-Commerce Controls
Paperwork without paper
Businesses used to post each other purchase orders and invoices. Each paper document carried a signature, a letterhead and a postmark: evidence of who sent what, and when. If there was a dispute, you pulled out the paper.
Electronic data interchange (EDI) replaces those documents (purchase orders, invoices, shipping notices) with standard electronic messages sent directly between trading partners’ systems. It’s faster and cheaper, but every piece of evidence the paper used to give you now has to be designed into the system.
How an EDI order travels
The components:
- Communications handler: sends and receives the messages (via a value-added network, AS2, SFTP or APIs).
- EDI interface, in two parts: the translator converts between a standard format (such as EDIFACT or ANSI X12) and the company’s internal format; the application interface moves data to and from the application.
- Application system: actually processes the order or invoice.
What can go wrong
- Unauthorised transactions: someone pretending to be a trading partner, or staff placing orders they shouldn’t
- Lost or duplicated messages
- Integrity: data changed in transit or garbled in translation
- Repudiation: a partner denies sending or receiving something
- No paper audit trail
- Dependence on the network provider and the partner’s systems
The controls
| Area | Controls |
|---|---|
| Legal | Trading partner agreement: responsibilities, liability, standards, dispute resolution |
| Authentication and authorisation | Partner authentication; authorisation inside the application; limits on what EDI can trigger |
| Completeness | Sequence numbers, control totals in the message envelope, acknowledgements |
| Integrity and confidentiality | Encryption, hashing, digital signatures |
| Validation | Edit checks on inbound data, just like any other input |
| Audit trail | Logs of every message, translation and acknowledgement |
| Exceptions | Rejected and unacknowledged messages followed up |
The acknowledgement trap
A functional acknowledgement says only “message received, and the format is valid”. It doesn’t mean the supplier accepts the order; that needs a business-level reply. And acknowledgements are useless unless someone chases the ones that never arrive.
Example. A supplier says it never received a large order sent by EDI, and production stops while waiting for parts. The buyer’s logs show the message was sent, but no functional acknowledgement came back and nobody was monitoring for missing ones. The control gap: no follow-up of unacknowledged messages.
E-commerce
| Model | What it is |
|---|---|
| B2C | Businesses selling to consumers online |
| B2B | Businesses trading with each other, including EDI and supplier portals |
| B2G | Businesses dealing with government (tax filings, procurement) |
| C2C | Consumers trading through platforms |
Risks: payment fraud, theft of card and personal data, privacy breaches, outages and DDoS attacks, fake identities, customers denying orders (repudiation), and legal questions about which country’s law applies.
Controls:
- TLS for confidentiality and integrity in transit
- strong customer authentication and fraud monitoring
- digital signatures where non-repudiation is needed
- PCI DSS compliance for card data, or handing card handling to a payment provider
- privacy notices and consent
- availability and DDoS protection
- complete audit trails of orders and payments
Encryption gives confidentiality. Only digital signatures give non-repudiation.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Control that detects lost EDI messages | Sequence numbers / acknowledgements |
| What a functional acknowledgement confirms | Receipt and syntax, not business acceptance |
| Control providing non-repudiation | Digital signatures |
| Document setting the legal terms of EDI | Trading partner agreement |
| EDI component that converts formats | Translator (EDI interface) |
In short
- EDI exchanges business documents (orders, invoices) electronically in standard formats between trading partners.
- EDI components: communications handler, EDI interface (translator and application interface), and the application system.
- Key EDI risks: unauthorised transactions, loss or duplication of transactions, data integrity, and lack of evidence of origin and receipt.
- EDI controls include trading partner agreements, authentication, encryption, sequence numbers, control totals, functional acknowledgements and audit trails.
- E-commerce risks include fraud, privacy breaches, availability, and repudiation of transactions.
- Digital signatures provide authentication, integrity and non-repudiation; TLS provides confidentiality and integrity in transit.
Exam traps
- A functional acknowledgement confirms receipt and syntax, not that the business accepts the order.
- Encryption gives confidentiality; non-repudiation needs digital signatures.
- Lack of paper documents means the audit trail must be designed into the system.
- The trading partner agreement sets legal obligations; without it, disputes are hard to resolve.
Slides
Click the slide and use the arrow keys. F toggles full screen.
How an EDI order travels
Risks and controls