Security by envelopment – a novel approach to data-security-oriented configuration of lightweight-automation systems

Figures & data

Figure 1. Envelopment concept.

Table 1. The main events during the project and the data sources.

Month and intervention cycle (if applicable)	Event	Data sources
June 2018	Country-specific mapping of the requirements set by the Posted Workers Directive	Meetings with service co-ordinators.
July 2018	Deciding on a centralised rather than a decentralised governance model	Meetings with candidate groups of employees for handling notifications Briefing of local HR contacts
August 2018 (first BIE cycle)	The decision to divide the software robot into two parts, with the component accessing human resources SAP system information to run on a separate server	Meetings with the human-resources SAP system’s owner and other productowners
September 2018 (second BIE cycle)	The decision to use a database to store data (the software robots would utilise this database also to pass certain information between systems)	Meeting with RPA experts
October 2018 (third BIE cycle)	The decision to use Power BI for sharing information on travelling engineers with local HR contacts	Meeting with Power BI and Qlik Sense experts
December 2018	Acceptance of the artefact	Presentation of the RPA pilot artefact
December 2021	Retrospective reflection on the project and on the artefact developed	Interviews with two key stakeholders of the project (internal evaluation)
December 2022	Critical evaluation of the design principles’ reusability	Applicability checks with RPA practitioners (external evaluation)

Figure 2. The building–intervention–evaluation process.

Figure 3. The reporting process from the employee’s perspective.

Figure 4. Software robot v. 1.

Figure 5. The e-mail reading process.

Figure 6. Software robot v. 2 (alpha version).

Figure 7. Software robot v. 3 (beta version).

Figure 8. Software robot v. 4 (release 1).

Table 2. The design principles in summary.

Design principle	Meta-requirements addressed	Description
DP1: The Principle of Envelopment	R1, R2, R3	To aid in developers’ design of secure software robots, make enterprise architecture design choices that support the creation of envelopes for software robots; they allow the compartmentalisation of mindless software robots and afford enhanced control over the robot, such as removal of temporary-use data.
DP2: The Principle of Access Control	R1, R2	So that developers can design software robots that operate securely, establish practices for the organisation that involve strict control of access to the robotic systems. Such practices enable restricting unauthorised access and ensuring that the robot’s actions are confined to only the data needed for the operation.
DP3: The Audit-Trail Principle	R1, R4	To afford developers’ design of secure software robots, set up an audit trail to allow tracing and review of the software robot’s actions; this trail assigns emulated accountability, a feature necessary for analysis of the thoroughness of the robot’s operations and any misuse.

Table B1. The applicability sessions.

Session	Informants	Format
Session 1	Solutions consultant Technology lead	Face-to-face
Session 2	Head of business development	Virtual, via Zoom
Session 3	Director of automation	Face-to-face