Learning Objectives
By the end of this chapter, you will be able to:
- Distinguish policies from procedures (a common 1-mark exam pair).
- Explain risk assessment, a written security policy, roles, incident response, and audit.
- Describe, at teaching depth (not legal advice), how Nepal public law and payment rules shape e-commerce security.
- Treat PCI-DSS as a management decision about scope, not only a technical control.
Why technology is not enough
Firewalls, TLS, and antivirus reduce risk, but they do not decide who may access customer data, how a breach is reported, or whether the firm is allowed to store card numbers. Management sets goals and rules; procedures turn those rules into repeatable steps; public laws set the outer boundary of what is legal.
A Kathmandu merchant can buy a TLS certificate in an afternoon. Without access-control policy, staff still share one admin password on a WhatsApp group. That is a management failure, not an encryption failure.
Policies versus procedures
| Policy | Procedure | |
|---|---|---|
| What it is | A high-level rule: what must happen and why | A step-by-step method: how to do it |
| Example | “Customer passwords shall never be stored in plaintext.” | “Hash with the approved algorithm; rotate secrets via the vault; ticket number required to export a user list.” |
| Change frequency | Slow; approved by management | Faster; operations can refine steps |
| Exam use | Goals, principles, accountability | Checklists, runbooks, SAQ evidence |
Business procedures in e-commerce also include non-IT steps: refunds, KYC for wallet top-ups, who can issue a discount code, how COD cash is reconciled. Weak procedures (no dual control on refunds) create fraud even when the website is patched.
Risk assessment
A risk assessment identifies assets (customer PII, payment tokens, warehouse APIs), threats (phishing, insider refund fraud, DDoS), likelihood, and impact. The output is a prioritised list so the firm spends first on high-impact, likely events (for example lost admin phones) rather than exotic threats.
Typical steps: inventory systems and data; map threats to the six security dimensions (integrity, nonrepudiation, authenticity, confidentiality, privacy, availability); score; choose treat / transfer / accept / avoid; review after incidents or major releases (festival traffic, new gateway).
Written security policy and roles
A security policy names owners (who is accountable), acceptable use, data classification (public / internal / confidential), access control, vendor rules, and what happens in a breach. It should be short enough that staff can be trained on it.
Roles to name in an exam answer: management (budget and risk appetite), IT/security (controls), operations (fulfilment and COD), customer support (reset and refund procedures), legal/compliance (notices and regulator contact). Small Nepali shops often combine these roles; the exam still wants the functions, not a large org chart.
Incident response
An incident response procedure answers: how do we detect (logs, customer complaints, bank chargebacks)? Who is on the call tree? When do we take the store offline? How do we preserve evidence? Whom do we notify (customers, bank, NRB-supervised PSP, police/cyber cell as applicable)? After-action review feeds the next risk assessment.
Auditing
A security audit checks whether policies and procedures are followed and still fit the threat. Internal audits (spot-check refund logs) and external audits (PCI QSA, ISO 27001) produce evidence. For a 3-mark question: audit is not the same as a one-time risk assessment; it is periodic verification.
Public laws and rules (Nepal context)
This is teaching context for IT 204, not a substitute for a lawyer. Names and years help 3–5 mark answers; always add “comply with current official text.”
Electronic Transactions Act, 2063 (2008 AD). Recognises electronic records and digital signatures, and addresses computer-related offences (unauthorised access, damage to data, publication of illegal material, etc.). For e-commerce it supports the idea that online contracts and records can have legal effect, and that tampering with systems can be an offence—not only a “IT problem.”
Privacy Act, 2075 (2018). Limits how personal information may be collected, used, and disclosed. E-commerce sites that collect names, phones, addresses, and order history should have a clear purpose, minimise data, and control access. Privacy notices and staff procedures are how policy meets this Act in practice.
Nepal Rastra Bank (NRB) and payment service providers. Wallets, QR (for example Fonepay rails), and many gateways operate under payment-system oversight. Merchants should use licensed PSPs, follow KYC/transaction-limit rules the PSP imposes, and not invent “unofficial” cash-in channels. Exam point: payment security is partly regulatory, not only SSL.
PCI-DSS as a management obligation. If you accept cards, card-brand rules require a PCI programme: reduce scope (hosted payment page / tokenization so card data never touches your server), complete the right SAQ, and maintain procedures (no storing CVV, access logs). See the PCI gateway case. Choosing SAQ A versus storing cards yourself is a management decision with cost and liability, not only a developer preference.
Other policies students may mention: consumer protection and refunds, domain/trademark, and platform terms (Daraz seller rules). Do not invent extra “cyber acts” unless the instructor has specified a later statute.
Putting it together (exam paragraph)
A complete 5-mark answer typically has four parts: (1) technology is insufficient; (2) policy vs procedure with one example; (3) risk assessment + policy + audit cycle; (4) at least one Nepal public-law or NRB/PCI management point.
Summary
Management policies state what must be protected and who is responsible. Procedures state how staff operate day to day. Risk assessment sets priorities; incident response and audit close the loop. In Nepal, ETA 2063, the Privacy Act 2018, NRB/PSP rules, and PCI-DSS (if cards) sit outside the firewall but inside a competent security plan.
Key Takeaways
- Policy = rules and intent; procedure = steps and evidence.
- Risk assessment ranks threats so spending matches impact.
- Incident response and audit turn a document into an operating system.
- Public law and payment regulation constrain design; PCI-DSS is a scope and process choice.
- This note is not legal advice.
Discussion Questions
- Differentiate policies and procedures with one e-commerce example of each.
- Why does a written security policy still matter for a three-person online shop?
- What should a risk assessment include before Dashain traffic spikes?
- How do the Privacy Act 2018 and PCI-DSS change what a merchant is allowed to store?
- Who should be on an incident-response call list for a wallet-checkout outage?
