I agree with you on this, Kars. Organizational policies can be very useful both as an alternative form of delegation of desirable outcomes (you don't hardcode something in code, but you mandate the creation of procedures surrounding the use of the system) as well as for setting meta policies such as review. So, the reduction of design to technical measures, which I take as a starting point for the discussion, feels like something of a missed opportunity for regulation.
Hi Marco, you raise some interesting points. I think one thing to consider is that design can encompass more than merely what is implemented in code, but may also include things like policy. This could go some way towards solving the issue of technical systems becoming out of step with (interpreted) law, if we ensure (by design) that code gets regularly reviewed for such things.
I agree with you on this, Kars. Organizational policies can be very useful both as an alternative form of delegation of desirable outcomes (you don't hardcode something in code, but you mandate the creation of procedures surrounding the use of the system) as well as for setting meta policies such as review. So, the reduction of design to technical measures, which I take as a starting point for the discussion, feels like something of a missed opportunity for regulation.
Hi Marco, you raise some interesting points. I think one thing to consider is that design can encompass more than merely what is implemented in code, but may also include things like policy. This could go some way towards solving the issue of technical systems becoming out of step with (interpreted) law, if we ensure (by design) that code gets regularly reviewed for such things.