68 lines
4.8 KiB
Markdown
68 lines
4.8 KiB
Markdown
---
|
|
title: 'The 5 Lines of Defence for Business Data Inputs'
|
|
description: How Data Controller for SAS® defends data quality for workflows deriving from business inputs - data model, permissions, validation checks, post edit hooks, and approvals.
|
|
date: '2026-08-27 09:00:00'
|
|
author: 'Allan Bowe'
|
|
authorLink: https://www.linkedin.com/in/allanbowe/
|
|
tags:
|
|
- Announcements
|
|
previewImg: './five-lines-of-defence.jpeg'
|
|
---
|
|
|
|
How does Data Controller for SAS® defend data quality for data workflows deriving from business inputs?
|
|
|
|
**⚔️ 1st Line of Defence - Data Model ⚔️**
|
|
|
|
The interface will only accept inputs conforming to this model (columns, types, lengths, indexes, constraints etc). The schema determines the behaviour - eg, a date format results in a date picker.
|
|
|
|
**⚔️ 2nd Line of Defence - Data Permissions ⚔️**
|
|
|
|
Changes are made using a SAS System Account (eg `sassrv`). This means you can safely DENY write-access to data for business users, preventing un-controlled data ingestion.
|
|
|
|
**⚔️ 3rd Line of Defence - Validation Checks ⚔️**
|
|
|
|
Additional validation checks (eg value ranges, specific patterns) can be configured to run at the point of data capture, prior to SAS upload. See the [validation documentation](https://docs.datacontroller.io/dcc-validations/) for details.
|
|
|
|
**⚔️ 4th Line of Defence - Post Edit Hook ⚔️**
|
|
|
|
Complex / customer specific validation can be deployed as SAS code, to run after every EDIT (prior to APPROVAL) using a [post edit hook](https://docs.datacontroller.io/dcc-tables/#post_edit_hook). A failure here results in immediate user feedback / change rejection.
|
|
|
|
**⚔️ 5th Line of Defence - Approval Step(s) ⚔️**
|
|
|
|
Changes are reviewed with [one or more approvals](https://docs.datacontroller.io/dcc-tables/) BEFORE being applied to the target database. A full audit trail is also maintained.
|
|
|
|
All functionality is ZERO-CODE, works on SAS Viya / EBI / SASjs Server, and applies to any database you have an ACCESS engine for. There is also a [community edition](https://datacontroller.io/pricing/) - free for unlimited users.
|
|
|
|
If you'd like to strengthen your own defences - [let's chat](https://datacontroller.io/contact/).
|
|
|
|
<!--
|
|
Source LinkedIn post:
|
|
|
|
How does Data Controller for SAS® defend #DataQuality for #DataWorkflows deriving from Business Inputs?
|
|
|
|
⚔️ 1st Line of Defence - Data Model ⚔️
|
|
The interface will only accept inputs conforming to this model (columns, types, lengths, indexes, constraints etc). The schema determines the behaviour - eg, a date format results in a date picker.
|
|
|
|
⚔️ 2nd Line of Defence - Data Permissions ⚔️
|
|
Changes are made using a SAS System Account (eg `sassrv`). This means you can safely DENY write-access to data for business users, preventing un-controlled #DataIngestion.
|
|
|
|
⚔️ 3rd Line of Defence - Validation checks ⚔️
|
|
Additional validation checks (eg value ranges, specific patterns) can be configured to run at the point of data capture, prior to #SAS upload. The docs for these are here: https://lnkd.in/djtaGPsr
|
|
|
|
⚔️ 4th Line of Defence - Post Edit Hook ⚔️
|
|
Complex / customer specific validation can be deployed as SAS code, to run after every EDIT (prior to APPROVAL). A failure here results in immediate user feedback / change rejection.
|
|
|
|
⚔️ 5th Line of Defence - Approval Step(s) ⚔️
|
|
Changes are reviewed with one or more approvals BEFORE being applied to the target database. A full audit trail is also maintained.
|
|
|
|
All functionality is ZERO-CODE, works on #sasViya / EBI / SASjs Server, and applies to any database you have an ACCESS engine for. There is also a Community edition - free for unlimited users.
|
|
|
|
#datagovernance #sasadmin #saspartners
|
|
-->
|
|
|
|
<!-- Image prompt:
|
|
A flat-design illustration in the Data Controller brand style (dark navy background, teal/green and orange accents), composed around a SINGLE CENTRAL focal point so it survives a square crop: a medieval-castle motif reimagined as a data fortress - five concentric defensive walls (rendered as clean glowing ring segments, each a slightly different teal/green shade, subtly numbered 1-5) surrounding a central database cylinder that glows safely at the core. An arrow or data-packet stream approaches from the top, passing checkpoints in each wall: a schema/grid icon (wall 1), a padlock (wall 2), a checklist with ticks (wall 3), a code angle-brackets icon (wall 4), and a stamp/approval tick (wall 5). One red/orange invalid packet is shown bouncing off an outer wall. All key elements within the central square of the frame; outer left and right thirds contain only background texture and glow, safe to crop. Minimal text, no logos. Professional but lightly playful, suitable for a B2B data product site. 16:9 landscape, 1200x627, suitable as a blog/feed cover image.
|
|
|
|
Generated with: local Routstr node (see blog-dev/skills routstr-image-generation), model gemini-3.1-flash-lite-image, output 1424x736 JPEG, ~31 sats.
|
|
-->
|