Safety Norms: Business Intelligence Development

1Purpose, Scope, and Safety Principles

These norms protect the people, information, and equipment involved in business intelligence development. Business intelligence (BI) development means building the pipelines, data models, calculations, dashboards, and reports that turn operational records into information for managers. The scope includes developers, analysts, data engineers, database administrators, testers, and the business owners who approve requirements and use the outputs. It applies to work performed on company laptops, development and test servers, cloud workspaces, and office or remote workstations.

Three principles guide every rule in this document. First, data is handled according to its sensitivity, not its convenience. Second, a report is only fit for use when its figures have been checked against an agreed source. Third, anyone who sees a risk stops and reports it before continuing.

• Mandatory: Use only approved data sources, tools, and environments for each task.
• Recommended: Treat each new dashboard as a small product with a named owner, a stated purpose, and a planned end of life.

2Roles, Competence, and Accountability

The data owner approves who may see each dataset and what purpose it serves. The BI lead owns the solution design, change control, and release approval. Developers build and test to the approved design. The security or privacy officer sets handling rules for personal and confidential data, and the facilities or IT team maintains the physical and network environment. Each role must be named in the project record.

Competence comes before access. Developers must complete the onboarding for the data platform, the privacy training required by their organization, and any vendor training needed for the tools they administer. Where local law or company policy requires certification or licensing for database administration or security roles, verify the current requirements with the responsible authority. This guidance does not grant authorization to administer production systems.

• Mandatory: Access to production data requires a written request approved by the data owner and the BI lead.
• Mandatory: Shared or generic accounts must not be used to access data sources or publish reports.
• Recommended: Pair new developers with an experienced reviewer for their first two releases.

3Course-Specific Hazards and Risk Assessment

BI work carries less physical danger than laboratory or field work, but its hazards are real. The main risks are harm to people from exposed personal data, financial or operational harm from wrong figures, loss of confidential information, and musculoskeletal or eye strain from long periods at screens. Physical risks include electrical contact in server rooms, tripping over cables, and heat or fire from overloaded power strips. Estimate risk as likelihood multiplied by severity and record each rating in the project risk register.

• High: Exposure of employee, customer, or patient records through copied extracts, email attachments, or poorly secured cloud storage. Control: encryption at rest and in transit, masking of identifiers in development copies, and regular access review.
• High: Credentials stored in scripts, notebooks, or repositories. Control: a secrets manager and automated secret scanning before any commit.
• Medium: Incorrect calculations, duplicate counts, or stale refresh schedules that drive wrong business decisions. Control: reconciliation to source totals and documented test cases.
• Medium: Performance overload that slows transactional systems during business hours. Control: query review and scheduled loads outside peak periods.
• Medium: Musculoskeletal strain and eye fatigue from prolonged screen work. Control: adjustable workstations, regular breaks, and an ergonomic assessment.
• Low to medium: Electrical or heat hazards in server closets and equipment rooms. Control: restricted access, cable management, and facilities inspection.
• Low: Accidental deletion of shared reports or models. Control: version control and backups verified by the platform team.

4Preventive Controls and Safe Work Practices

Preventive controls work in layers. Design controls come first: collect only the data the question requires, use the least sensitive identifier that answers it, and separate development from production. Administrative controls come next, including approvals, peer review, and written procedures. Technical controls such as role-based access, row-level security, audit logging, and automated tests form the final layer. Relying on a single layer, or on memory and good intentions, is not acceptable.

Safe practice begins with the request. Before building anything, confirm the business purpose, the lawful basis for using the data as your organization defines it, the retention need, and who will receive the output. Record these answers in the requirements document. If the purpose is unclear or the data is more sensitive than the purpose needs, stop and escalate to the data owner.

• Mandatory: Develop against masked or synthetic data wherever the question can be answered without identifiable values. Confirm what counts as identifiable with privacy guidance in your jurisdiction.
• Mandatory: Never export production data to personal devices, personal email, consumer file-sharing services, or unapproved AI tools.
• Mandatory: Store credentials only in the approved secrets manager. Rotate any credential that appears in a file, chat, or screenshot, and report the exposure.
• Mandatory: Every change to a data model, transformation, or calculation goes through version control, peer review, and testing before release.
• Mandatory: Reconcile each new or changed report to an agreed control total from the source system and record the result. Do not publish until any variance is explained and approved.
• Mandatory: Keep development, test, and production environments separate, with production changes made only through the approved release process.
• Mandatory: Apply least privilege. Grant read access only to the tables, columns, and rows needed for the role.
• Recommended: Use a standard naming convention and data dictionary so that metrics mean the same thing across dashboards.
• Recommended: Schedule heavy extracts and model refreshes outside peak business hours, and monitor run times against an agreed threshold.
• Recommended: Lock your screen whenever you leave the desk, and avoid viewing dashboards containing personal data in shared or public spaces.
• Recommended: Store printed reports in locked storage and shred printed extracts when they are no longer needed.

5Equipment, Environment, Information, and Protective Safeguards

Developers rarely need personal protective equipment for core tasks, but protective safeguards still matter. Workstations should allow a neutral wrist posture, screen height at or near eye level, and a chair that supports the lower back. Where a sit-stand desk is provided, change position regularly. Only trained facilities or IT staff may enter server rooms, and any hearing or other protection required by the site must be worn. Verify occupational safety and ergonomic requirements with the employer's safety officer and competent authorities.

Information safeguards are the main protective equipment in this field. Use multi-factor authentication on every BI platform, encrypted laptops, privacy filters in shared spaces, and approved collaboration channels. Enable audit logs for sensitive models. Environmental controls include adequate ventilation and temperature in equipment rooms, fire suppression maintained by facilities, and uninterruptible power for on-premises servers. Equipment must be used according to manufacturer instructions and the platform vendor's documented limits.

• Mandatory: Enable full-disk encryption and automatic screen lock on every device used for BI work.
• Mandatory: Do not use personal storage devices to carry extracts.
• Recommended: Use a monitor arm and external keyboard for extended sessions.
• Recommended: Dispose of old hardware and storage media through approved channels that sanitize or destroy data, following local regulations.

6Incident Reporting, Emergency Response, and Escalation

Report every incident and near miss within the timeframe set by company policy. A near miss is an event that could have exposed data, produced a wrong figure, or harmed a person but did not. Examples include a report sent to the wrong distribution list, a notebook committed with a password, or a dashboard total that fails reconciliation. Do not wait to confirm the impact before reporting.

For suspected data breaches, ransomware, or compromised accounts, disconnect the affected device from the network if it is safe to do so, leave files and logs unchanged, and contact the security team through the emergency channel. For fire, medical emergencies, electrical shock, or evacuation, follow the site alarm and evacuation plan and call local emergency services. Do not attempt to rescue a person from energized equipment without training. Breach notification duties are set by law and vary by jurisdiction. The privacy officer decides on any external notice, with legal advice.

• Mandatory: Report suspected breaches to the security team immediately, even if unconfirmed.
• Mandatory: Preserve evidence such as query logs, access records, and message headers.
• Mandatory: Escalate any wrong figure that has reached executives to the BI lead and data owner, and withdraw the report until it is corrected.
• Recommended: Hold a short blameless review after each significant incident and record corrective actions with named owners.
• Recommended: Keep a current contact list for security, privacy, facilities, and vendor support.

7Records, Training, Inspection, and Review

Records prove that controls operate. Maintain the requirements record, data lineage documentation, access approvals, change tickets, test results, reconciliation evidence, and incident logs. Retain them for the period set by the records policy and destroy them securely when that period ends. Refresh training whenever tools, privacy rules, or company policy change.

Monitoring should be routine. Review access lists against staff changes, examine failed login alerts, check report usage to retire stale dashboards, and inspect workstations and server closets against a written checklist. Use the results to update these norms. Review this document at regular intervals, after any significant incident or major platform change, and verify it against current law and vendor guidance with qualified staff.

• Mandatory: Remove access within the period set by the access policy when a person changes role or leaves.
• Recommended: Track report usage and retire unused dashboards to reduce exposure and maintenance load.
• Recommended: Run a tabletop exercise on a data breach scenario during each review cycle.

8Conclusion and Checklist

Safe business intelligence development depends on disciplined habits as much as technical skill. Clear roles, approved access, reconciled outputs, and prompt reporting protect people and decisions alike. Treat this document as a starting point. Adapt it into locally approved procedures, and confirm every legal, ergonomic, and vendor requirement with the responsible authority before relying on it.

Implementation checklist

• Confirm the business purpose, data owner, and retention need before building.
• Use masked or synthetic data in development unless an approval states otherwise.
• Check that each access grant is individual, approved, and limited to the minimum needed.
• Store secrets only in the approved vault and rotate any exposed credential.
• Peer review and test every change, and keep it under version control.
• Reconcile each report to a source control total and record the result.
• Make production changes only through the approved release process.
• Report near misses and suspected breaches immediately, and preserve logs.
• Set up the workstation for neutral posture and take regular breaks.
• Remove access and dispose of storage media through approved channels when roles or hardware change.