Policies, Standards & Controls

A policy is a promise about how people will behave. A standard says exactly how. A control is the check that proves it. Together they turn good intentions into daily practice. This lesson shows how to write a short AI policy that staff will read, how to build standards under it and how to design controls you can test.

The three layers

• Policy: short, stable, written for everyone. It says what we do and why.
• Standards: specific rules for teams, such as how to test or how to handle data. They change more often.
• Controls: the actual checks and tools that make the standards real, such as a review step or a block on certain data.

A policy people read

Aim for two pages. Use plain words. Answer the questions people really ask.

1. PURPOSE AND SCOPE      Why we have this; who it covers (staff, contractors, vendors)
2. PRINCIPLES             A few short statements: safe, lawful, fair, transparent, accountable
3. ALLOWED TOOLS          Approved tools; how to ask for a new one
4. DATA RULES             What may go into AI tools; what must never go in
                          (e.g. customer personal data, secrets, regulated data)
5. HUMAN RESPONSIBILITY   People are responsible for AI-assisted work; check before you use it
6. HIGH-RISK USES         Need review before launch (link to the tiers)
7. TRANSPARENCY           When we tell customers or staff that AI is involved
8. REPORTING              How to report a problem or a concern; no blame for good-faith reports
9. ROLES                  Who owns the policy; who approves exceptions
10. REVIEW                How often the policy is updated

Standards under the policy

• Data handling: which data classes may go to which tools and regions.
• Testing: what evidence each tier needs before launch.
• Human oversight: when a person must approve, and how to make that review real.
• Documentation: what must be written down about each system.
• Monitoring: what is watched after launch, and how often.
• Procurement: questions every AI vendor must answer.
• Incident handling: how to report and respond.

Design controls that can be tested

A control is good if you can show it works. Write each control with an owner, a frequency and a way to test it.

CONTROL: No customer personal data in unapproved AI tools
TYPE: Preventive (blocks)   |   Detective (finds)   |   Corrective (fixes)
OWNER: IT security
HOW IT WORKS: The network gateway blocks unapproved AI sites; approved tools sit behind login
              with data-loss rules for personal data patterns
FREQUENCY: Continuous
HOW WE TEST IT: Each quarter, try five blocked actions and review the gateway logs
EVIDENCE: Test report, log extract, list of approved tools
LAST TESTED: {{date}}     RESULT: {{pass / fail / action}}

Prevent, detect, correct

• Preventive controls stop a problem: blocks, approvals, permissions.
• Detective controls find a problem: logs, alerts, audits, sampling.
• Corrective controls fix a problem: rollback, retraining, incident plans.

A good design uses all three. Prevention alone fails sometimes. Detection alone comes too late.

Exceptions

Sometimes a team needs to step outside the rules. Allow it with a written exception: who asked, why, what risk, what extra controls, who approved and when it ends. Track them. A pile of old exceptions means the standard is wrong.

Keep it short and current

• Review the policy at least once a year, and when laws or tools change.
• Retire rules nobody follows. Unused rules weaken the rest.
• Publish it where people look, and show examples of allowed and not allowed uses.
• Measure: do people know the policy? Ask three questions in a survey.