Chapter 2 — Scope, permission and safe practice
Lesson map
Lesson 02 published. Map, example, EX014.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Permission"]
N2["2.2 Scope"]
N3["2.3 Safe practice"]
N4["2.4 Donor data"]
N5["2.5 Defensive only"]
N6["2.6 When to ask for help"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX014"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Permission"]
N2["2.2 Scope"]
N3["2.3 Safe practice"]
N4["2.4 Donor data"]
N5["2.5 Defensive only"]
N6["2.6 When to ask for help"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX014"]
[Learning outcomes]
|
v
[2.1 Permission]
|
v
[2.2 Scope]
|
v
[2.3 Safe practice]
|
v
[2.4 Donor data]
|
v
[2.5 Defensive only]
|
v
[2.6 When to ask for help]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX014]
Learning outcomes
You will (1) confirm permission before checking or changing the website; (2) set clear scope; (3) work safely with backups and staging; (4) protect donor data.
2.1 Permission
Owen is employed by the charity, but changes to the website still need the director's agreement, recorded in an email that names what he will check and change. The website host's terms also say what customers may test. Owen checks only the charity's own site and accounts; he does not probe the host's systems or other sites.
The director's reply adds a condition: she wants to be told before any change that donors could notice. Owen treats the donate-form update as such a change and tells her before releasing it. Keeping the permission in an email means that, if something goes wrong, there is a record of what was agreed and by whom.
2.2 Scope
The scope for the month: the donation website, its administrator accounts, its plugins and theme, and the charity's account with the website host. Out of scope: the payment provider's systems, which belong to the provider, and volunteers' personal devices.
Leaving out the payment provider is a limit, not an oversight: card details go straight to the provider's page, and Owen has no right to test its systems. He checks only the hand-off, that the donation form sends donors to the provider's real page. In his final presentation he names this as one of the things he cannot check himself.
2.3 Safe practice
Before any change, Owen takes a full backup and confirms it can be restored. He tests updates on a staging copy, a private copy of the site with donor data removed or replaced by synthetic records. He makes one change at a time and notes it in a simple change log.
Owen proves the backup works before relying on it: he restores it once to staging in the first weeks. That restore also gives him the staging copy where he later tests the donate-form update with synthetic donations. Each line in the change log says what changed, when, and how to undo it, which is what the director needs if donors report a problem.
2.4 Donor data
The site stores donor names, emails and donation amounts; card details stay with the payment provider. Owen never copies donor data to his own devices and uses synthetic records for testing.
This rule also shapes the staging copy: it holds synthetic donors, so testing the donation form there cannot leak a real person's details. When event-calendar turned out to store volunteers' phone numbers, the same thinking applied: those numbers moved to the charity's volunteer system and were deleted from the website.
2.5 Defensive only
The course teaches checking and fixing, not attacking. Owen does not run tools that try to break into the site; he reviews versions, settings and logs.
His checks are all of this kind: the plugin list from the administration page, version numbers compared with published advisories, the hash of a download compared with the vendor's, and the list of administrator accounts. None of them sends unusual requests to the site, so none can break it or upset the host. If he wanted a deeper test, it would need the host's permission and a professional tester.
2.6 When to ask for help
If he sees signs that the site has already been misused, such as unknown administrator accounts, Owen stops, preserves evidence and contacts the host's support and Nadia.
Preserving evidence means not deleting the unknown account straight away: Owen notes its name and creation date, takes a screenshot, and asks the host for the access logs before anything changes. Deleting first might stop the attacker, but it would also remove the clues to how they got in and what else they touched. In Owen's month, the monthly account review found no unknown accounts.
Worked example
Owen's permission email to the director lists the scope and says he will take backups, test on staging and keep a change log. The director replies with approval and asks to be told before any change that donors could notice. Owen restores a backup to staging once to prove it works before relying on it.
Synthetic case. Emails and systems are synthetic.
Errors and limits
Backups that have never been restored may not work.
Exercises
- EX014 — Permission form. How is Owen's permission recorded? Rubric: 3 = email naming checks and changes; 2 = partial; 1 = vague; 0 = none.
- EX015 — In scope. List the in-scope items. Rubric: 3 = site, admin accounts, plugins and theme, host account; 2 = three; 1 = one; 0 = none.
- EX016 — Out of scope. Name two out-of-scope items. Rubric: 3 = payment provider systems; volunteers' devices; 2 = one; 1 = vague; 0 = none.
- EX017 — Staging copy. What is a staging copy? Rubric: 3 = private copy with synthetic data; 2 = partial; 1 = vague; 0 = none.
- EX018 — Backup proof. How did Owen prove the backup works? Rubric: 3 = restored it to staging; 2 = partial; 1 = vague; 0 = none.
- EX019 — Card details. Where are card details stored? Rubric: 3 = with the payment provider; 2 = partial; 1 = vague; 0 = none.
- EX020 — Change log. Why keep a change log? Rubric: 3 = track one change at a time; undo; 2 = partial; 1 = vague; 0 = none.
- EX021 — Misuse signs. What should Owen do if he sees misuse? Rubric: 3 = stop, preserve evidence, contact host and tutor; 2 = two; 1 = one; 0 = none.
- EX022 — Defensive scope. What kind of tools does Owen avoid? Rubric: 3 = tools that try to break in; 2 = partial; 1 = vague; 0 = none.
- EX023 — Director request. What did the director ask for? Rubric: 3 = notice before donor-visible changes; 2 = partial; 1 = vague; 0 = none.
- EX024 — Donor data rule. How is donor data protected during testing? Rubric: 3 = never copied; synthetic records; 2 = partial; 1 = vague; 0 = none.
- EX025 — Host terms. Why read the host's terms? Rubric: 3 = they say what customers may test; 2 = partial; 1 = vague; 0 = none.
- EX026 — One change. Why make one change at a time? Rubric: 3 = easy to find what caused a problem; 2 = partial; 1 = vague; 0 = none.
Synthesis
Permission, scope, backups and staging make changes safe.
Continue studying — chapter 02 of 04
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →