A table is going to the warehouse. It carries employee names, bank accounts or identity numbers. One question gets asked in the meeting: can we mask this?
The question is incomplete. There are three routes on the table and masking is only one of them. Not knowing which one you chose is how a field ends up sitting in the target with nobody accountable for it.
Three routes, three different costs
Route one: never move the field. Narrow the field set of the transfer project or the service definition and the value never reaches the target. The cost is reopening the definition when somebody needs that field later; the gain is having no data to protect.
Route two: mask it. Masking rules and rule sets are defined to control how a sensitive value appears in output, and the selected rule set is bound to the fields of an SQL transfer project and carried into the field definitions of the SAP execution request. The cost is the duty of tracking which flow binds which field.
Route three: authorize it. By mapping report fields to authorization objects, or defining object and data authorizations on the BI side, you decide who sees the field. The cost is maintenance as people and roles change.
These are not alternatives but three controls working in different places: one never moves the data, one changes its appearance while it moves, one decides who sees it.
Where the rule set binds, and in which direction
Defining the rule set is the easy half. The hard half is that the same SAP field can be masked in one transfer project and appear raw in another output. So build the sensitive field list per flow: which project, which service, which report carries this field?
Direction matters too. A masking rule set applies to transfer fields moving from SAP to an external target. On projects that write from an external source into SAP, that masking is not applied, and data in that direction has to be handled at the source.
One more boundary: the rule set and the request payload are assembled on the application side, while the final masked value is produced on the SAP and service side. Which makes looking at a few rows in the target a required step at go-live, not an optional one.
The shortest check follows from that: open two outputs carrying the same field side by side. If it is masked in one and raw in the other, no decision was made — the rule was simply applied in a single flow.
The line where masking stops
Masking is not encryption; a masked value is not stored to be reopened with a key. The source data in SAP does not change either — this is an output decision, not a data correction.
It is not a compliance statement either. Its job is narrow and concrete: changing how a field appears in output according to a defined rule. Data classification, retention periods and access approvals sit outside that rule, and they usually do the real work.
A suggestion: open the field list of your busiest transfer project and write, next to every sensitive field, which of the three routes was chosen. If some rows come back blank, reviewing that table together is a good place to start.