SIAS-DAT-01 Data classification and handling rules
- Mandatory
- Yes
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Every data store in scope carries a classification, and each classification level comes with handling rules that people and systems can apply consistently.
Testable requirement
- (a)The applicant shall define a data classification scheme with at least three levels, one of which covers public data. The highest level (called "Restricted" in SIAS, whatever label the applicant uses) shall include at least: authentication secrets and cryptographic keys; payment card account data; health information; Social Security numbers and other government-issued identification numbers; financial account numbers together with any access code; biometric data; data the applicant must keep confidential under contract at the highest level; and personal information whose unauthorized acquisition would require notification under an applicable U.S. federal or state law. The applicant shall record which of its own levels corresponds to Restricted.
- (b)For each level, the applicant shall define handling rules covering: permitted storage locations; encryption at rest and in transit; who approves access; external sharing; labeling; use in non-production environments; retention and disposal; use on personal devices; and transfer to third parties.
- (c)The applicant shall assign a classification to every data store and data flow in the SIAS-DAT-02 inventory.
- (d)The applicant shall tag every cloud data store that holds Restricted data with its classification, where the platform supports resource tags or labels.
- (e)The applicant shall communicate the handling rules to its workforce through its acceptable-use rules (SIAS-GOV-02) and shall review the scheme at least every 12 months.
- Definitions used throughout SIAS: "Restricted data" means data at the applicant's level that corresponds to Restricted under requirement (a). "Sensitive data" means Restricted data, other personal information about individuals, and customer data the applicant holds under a confidentiality obligation.
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: not included.
Pass criteria
- 1.The scheme has at least three levels, and the Restricted level covers every minimum category in requirement (a) (M1).
- 2.The handling matrix defines every rule topic in requirement (b) for each level (M1).
- 3.Every data store in the SIAS-DAT-02 inventory has a classification (A1).
- 4.Every cloud data store holding Restricted data is tagged where the platform supports tags (A1).
- 5.No confirmed Restricted data remains in a store classified lower at decision; each instance found was reclassified or removed (A2, M2).
- 6.The scheme was reviewed in the last 12 months.
- 7.Each interviewed workforce member described where Restricted data may be stored and how it may be shared externally in line with the matrix. Each inconsistency is recorded (I2).
Severity
Medium. Standard escalation triggers apply: if discovery finds Restricted data exposed to unauthenticated parties, that exposure is recorded as a Critical finding against the most specific control (for example SIAS-CLD-03).
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- No direct mapping
- Trust Services Criteria
- C1.1
- ISO/IEC 27001:2022
- A.5.10, A.5.12, A.5.13
- Theme (SecurityInspect wording)
- tiered classification with defined handling
SIAS-DAT-02 Sensitive data inventory and data-flow map
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant knows every place in scope where sensitive data is stored or processed and every path it takes, including copies in logs, analytics, backups and third parties, so that nothing sensitive sits outside its controls.
Testable requirement
- (a)The applicant shall maintain an inventory of every location in scope where sensitive data is stored or processed, including databases, object storage, file shares, SaaS applications, logs, caches, exports, backups, analytics platforms, endpoint categories and third-party processors. Each entry shall show the data types, the classification, an order-of-magnitude volume, the owner, the system of record, the retention rule and whether the data is encrypted at rest.
- (b)The applicant shall maintain data-flow diagrams showing how sensitive data enters, moves within and leaves the scope, covering collection points, internal transfers, transfers to third parties, backups and log pipelines, and showing how each flow is protected (encryption in transit and authentication).
- (c)The applicant shall update the inventory and diagrams within 30 days of a material change to sensitive data stores or flows, and review them at least every 12 months.
- (d)The applicant shall use the inventory as an input to its risk assessment (SIAS-RSK-01).
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: not included.
Pass criteria
- 1.Every inventory entry has the required fields (M1).
- 2.The diagrams cover every collection point, internal transfer, third-party transfer, backup and log pipeline for sensitive data, and show how each flow is protected (M2).
- 3.No data store, log stream, integration or third party holding sensitive data that A1 to A4 or M3 found remains missing from the inventory or diagrams at decision (M4).
- 4.The inventory and diagrams were reviewed in the last 12 months and, for renewal, updated within 30 days of each material change in the look-back.
- 5.The SIAS-RSK-01 risk assessment references the inventory (M5).
Severity
High. Standard escalation triggers apply.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(1)(ii)(A)
- PCI DSS v4.0.1
- 1.2, 12.5
- Trust Services Criteria
- CC2.1, C1.1
- ISO/IEC 27001:2022
- A.5.9, A.5.12, A.5.14
- Theme (SecurityInspect wording)
- knowing where sensitive data lives and moves
SIAS-DAT-03 Data minimization, retention and secure deletion
- Mandatory
- No
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant collects only the sensitive data it needs, keeps it only for a defined period, and deletes it in a way that cannot be undone by ordinary means, including the copies.
Testable requirement
- (a)The applicant shall define a retention period and a documented purpose for each sensitive data type in the SIAS-DAT-02 inventory, based on business need and the obligations in the SIAS-GOV-04 register.
- (b)The applicant shall collect only the sensitive data fields that serve a documented purpose.
- (c)At the end of the retention period, the applicant shall delete or de-identify the data, using automated means where the platform supports them (for example lifecycle rules, time-to-live settings or scheduled jobs). This shall cover replicas, exports, analytics copies and logs. Backups shall expire under the backup retention schedule.
- (d)Deletion shall make the data unrecoverable by ordinary means. A logical "deleted" flag counts only when a purge follows within a defined period, and object versioning or soft-delete settings shall not keep data beyond the schedule.
- (e)The applicant shall carry out deletion requests owed under contract (for example at the end of a customer contract) within the contractual period and record completion.
- (f)The applicant shall keep records of deletion runs and completed requests for at least 12 months.
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: not included. Data under a documented legal hold is exempt from deletion while the hold lasts.
Pass criteria
- 1.Every sensitive data type in the inventory has a retention period and a documented purpose (M1).
- 2.Every data store holding sensitive data has a deletion or de-identification mechanism consistent with its period, and no versioning or soft-delete setting defeats it (A1, A4).
- 3.The age-band counts on sampled stores show no records more than 30 days past their retention period, other than records under a documented legal hold (A2, M3).
- 4.Scheduled deletion jobs ran as scheduled in the look-back, and each failure was detected and the job rerun (A3).
- 5.Each sampled contractual deletion request was completed within its contractual period, with a completion record that covers copies (M4).
- 6.Every field collected at the sampled collection points has a documented purpose (M2).
- 7.The observed deletion removed the synthetic record from every sampled location (M5).
Severity
Medium. Standard escalation triggers apply.
Informative framework mappings
- HIPAA Security Rule
- §164.310(d)(2)(i), §164.310(d)(2)(ii)
- PCI DSS v4.0.1
- 3.2
- Trust Services Criteria
- C1.2, P4 series
- ISO/IEC 27001:2022
- A.5.33, A.8.10
- Theme (SecurityInspect wording)
- keep only what is needed and delete it verifiably
SIAS-DAT-04 Non-production data and data leakage prevention
- Mandatory
- No
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- VP-APP
Control objective
Restricted data does not leak into test and development environments, appears in full only to people who need it, and cannot be moved out of approved locations without being stopped or noticed.
Testable requirement
- (a)The applicant shall not use Restricted production data in development, test, staging, demonstration or training environments unless it has been masked, tokenized, replaced with synthetic data or de-identified by a documented method. Where a copy of live Restricted data is strictly necessary (for example to reproduce a production fault), the copy shall be approved in writing, held in an environment with production-level access, encryption and logging controls, and deleted within 30 days.
- (b)The applicant shall mask or truncate Restricted values in application screens, exports and support tools for users whose role does not need the full value.
- (c)Where the corresponding capability is in scope, the applicant shall: restrict external and anonymous sharing of Restricted content in collaboration and file-sharing tenants; limit bulk export of sensitive data from production applications and databases to documented roles, and log each export; and operate automated detection of Restricted data patterns on at least one outbound channel that carries most of its external data transfers (for example email or web uploads from managed devices).
- (d)Test fixtures, seed files and database dumps held in source repositories shall contain no Restricted data.
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: VP-APP, where it applies to the named application, its non-production environments, its screens and exports, and its source repositories. If the applicant has no non-production environment (confirmed under SIAS-GOV-03), requirement (a) is met by that confirmation.
Pass criteria
- 1.No unapproved Restricted production data remains in non-production stores or source repositories at decision, and each approved live-data copy has production-level controls and is within its 30-day deletion period (A1, A2, M2, M3).
- 2.The masking method is documented and irreversible, or tokenized with separately held keys (M1).
- 3.Restricted values are masked in screens and exports for every tested role without a documented need for full values (A5, M4).
- 4.External and anonymous sharing of Restricted content is restricted in every in-scope collaboration tenant, and the controlled external-share test was blocked or alerted (A3, A6).
- 5.Bulk export is limited to documented roles and logged, and export alerts in the look-back were reviewed (A4, M5).
- 6.The controlled outbound test on the monitored channel was detected, or the applicant has documented that no outbound channel in scope carries sensitive data (A6).
Severity
High. Standard escalation triggers apply. Restricted data in a non-production environment that unauthenticated parties can reach is a Critical finding.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 3.4, 6.5
- Trust Services Criteria
- CC6.7
- ISO/IEC 27001:2022
- A.8.11, A.8.12, A.8.33
- Theme (SecurityInspect wording)
- masked test data and controlled data egress
