Chapter 10 — Ethics and authorized practice
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Permission"]
N2["10.2 Personal data"]
N3["10.3 Honesty"]
N4["10.5 Raising concerns"]
N5["Why authorisation matters"]
N6["Professional codes"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Permission"]
N2["10.2 Personal data"]
N3["10.3 Honesty"]
N4["10.5 Raising concerns"]
N5["Why authorisation matters"]
N6["Professional codes"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Permission]
|
v
[10.2 Personal data]
|
v
[10.3 Honesty]
|
v
[10.5 Raising concerns]
|
v
[Why authorisation matters]
|
v
[Professional codes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) work only with permission; (2) protect personal data; (3) communicate honestly with the partner.
10.1 Permission
Aisha's work at Bramley is covered by a written agreement signed by Bramley's chief executive and Dr Grant: read-only access to device reports, no access to tenant records and changes only through Gareth.
The agreement names what Aisha may see, who makes changes and what happens if she finds a problem. Read-only access means she can view device reports and exports but cannot change a setting on any laptop or server. Every change she recommends goes to Gareth, who decides whether to make it and records it in the change log.
10.2 Personal data
Device reports include staff names. Aisha uses roles in her reports and keeps raw exports on encrypted university storage.
Aisha replaces each name with a role, such as "finance manager" or "housing officer 3", before any table leaves the raw export. The mapping from role to name stays with Gareth, not with Aisha. Raw exports are kept on the university's encrypted storage and are deleted within a month of her capstone submission, as the agreement requires. Gareth checks one of her report tables before it is shared, confirming that no staff name has slipped through in a free-text comment field.
10.3 Honesty
She reports problems plainly, including those caused by past decisions.
At Bramley this means stating plainly that the stolen laptop was unencrypted because encryption had never been switched on. Aisha also reports the shared admin account and the 13 unencrypted laptops without softening them. She words each finding as a fact with its evidence, not as a judgement of Gareth, which keeps him willing to share more data with her. When her own early script printed nothing because of the "False" text bug, she recorded that mistake in her project log in the same plain way.
10.4 Limits
She does not test laptops for weaknesses or try to access data.
Aisha's work is limited to reading reports and configurations; she never runs scanners or tries passwords on Bramley's devices. When a question can only be answered by testing, such as whether a disabled service is really off, she asks Gareth to check it himself. Gareth records the result, so the evidence comes from an authorised person. The agreement also rules out running her own scripts on Bramley's machines; the labs run on her copies of exports or on synthetic data.
10.5 Raising concerns
If she sees something serious, she tells Gareth the same day.
The shared admin account in the worked example is the first time Aisha uses this route. She sends Gareth a short message the same afternoon, naming the server and the account without investigating how it was used. Gareth acknowledges it in writing, and Aisha keeps the message in her project log as evidence that she followed the agreement. Serious here means anything that could expose tenant data or let someone into a system without permission, such as a shared or default administrator account.
Why authorisation matters
Authorisation protects everyone. Without it, even helpful actions could break the law or Bramley's policies, and evidence Aisha collected could be questioned. With it, both sides know what she may do, and Bramley can show regulators and funders that the student project was controlled.
The agreement also covers what happens to data at the end: Aisha deletes her copies of exports within a month of submitting her capstone and confirms deletion in writing.
Professional codes
Professional bodies in computing publish codes of conduct that emphasise public interest, honesty and competence. Aisha reads one and notes how it applies to her work at Bramley, especially honesty about the limits of her skills.
Limits of the approach
No single control is perfect. Aisha notes where this one depends on people remembering, where it depends on reports that may be incomplete, and where it would fail silently. For each weakness she adds a simple check to the weekly routine, so failures become visible quickly.
Worked example
Aisha notices a shared "admin" account used on a server. She reports it to Gareth rather than investigating its use herself. Gareth disables it and creates named accounts.
Synthetic case. Synthetic.
Errors and limits
Good intentions do not replace authorisation.
Exercises
- EX028 — Agreement. What does the agreement permit? Rubric: 3 = read-only reports, no tenant data, changes via Gareth; 2 = two; 1 = one; 0 = none.
- EX029 — Names. How are staff names handled? Rubric: 3 = roles in reports, encrypted storage; 2 = partial; 1 = vague; 0 = none.
- EX030 — Shared admin. How was the shared admin account handled? Rubric: 3 = reported to Gareth; disabled, named accounts; 2 = partial; 1 = vague; 0 = none.
Synthesis
Work within permission and report concerns promptly.
Continue studying — chapter 10 of 40
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →