Hoofdstuk 6: Conclusie en aanbevelingen
6.3 Aanbevelingen
Zoals in de conclusie is beschreven, blijkt uit literatuuronderzoek en eigen analyse dat de voordelen die door middel van de Agile Scrum ontwikkel methode worden gerealiseerd bij IT projecten, ook tot toegevoegde waarde zal leiden wanneer dit wordt toegepast bij een audit methodologie. Helaas is zeer beperkt wetenschappelijk onderzoek uitgevoerd naar de toepassing van Agile Scrum als Audit methodologie. De verwachte toegevoegde waarde wordt echter wel bevestigd door middel van interviews van experts en ervaringsdeskundigen afgenomen in het kader van dit onderzoek. Desondanks bestaat er een zekere mate van scepsis ten aanzien van de haalbaarheid van een Agile Audit methodologie. Organisatorische aanpassingen zoals centralisatie van een audit afdeling, het aanbrengen van focus bij audits, het aanpassen van audit handboeken en gebruikte sjablonen en het teweeg brengen van cultuurverandering vereist significante investeringen en is niet van de ene op de andere dag gerealiseerd.
De scepsis kan alleen weggenomen worden door de Agile Audit methodologie in de praktijk toe te passen en vast te stellen dat voordelen zoals in de conclusie zijn beschreven ook in de praktijk gerealiseerd worden. De belangrijkste aanbeveling voor vervolg onderzoek zal derhalve ook zijn om de Agile Audit methodologie in de praktijk te toetsen.
Daarnaast is de Agile Audit methodologie zoals beschreven in dit onderzoek gericht op de uitvoering van een specifieke audit, oftewel de methodologie start op het moment dat een audit op het auditplan staat en er besloten is dat een audit uitgevoerd dient te worden. Gedurende verschillende interviews is het idee uitgesproken om de Agile Audit methodologie uit te breiden met het proces gericht op de totstandkoming van het audit plan. Op het audit plan staan namelijk de audits die gepland staan voor een bepaalde periode. Een hogere mate van flexibiliteit om in te kunnen spelen op nieuwe ontwikkelingen in de economische omgeving van organisaties en nieuwe risico
inschattingen, zou de relevantie van audits op het audit plan verhogen. Wellicht dat de Artefacten ‘Epics’ en ‘Features’ die in dit onderzoek niet zijn behandeld, hierbij een rol kunnen spelen.
43
Literatuurlijst:
Arnheiter, E. D., & Maleyeff, J. (2005). The integration of lean management and Six Sigma. The TQM Magazine, 5-18.
Balaji, S., & Sundararajan Murugaiyan, M. (2012). WaterFall Vs V-Model Vs Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), 26-30.
Beasley, M., Carcello, J., Hermanson, D., & Lapides, P. (2000). Fraudulent financial reporting: Consideration of industry traits and corporate governance Mechanisms. Accounting Horizons, 14(4), 441-454.
Beest, F. v., Braam, G., & Boelens, S. (2008). Nieuwe koers Conceptual Framework uitgezet. Accountancynieuws, 14-19.
Butera, A. (2016). Mastering the Five Tiers of Audit Competency : The Essence of Effective Auditing. Boca Raton: Auerbach Publications.
Chapman, C., & Anderson, U. (2002). Implementing the Professional Practices Framework. The Institue of internal auditors Research Foundation. Altamonte Springs, FL.
Coram, P., Freguson, C., & Moroney, R. (2008). Internal Audit, alternative audit structures an dthe level of misappropriation of assets fraud. Accounting and Finance, 48(4), 1-17.
de Korte, R., Bos, P., & Otten, J. (2015). Relevantie van audits: die hebben we zelf in de hand. Audit Magazine(2), 16-19.
Elliot, M., Dawson, R., & Edwards, J. (2006, March). Rowards real process improvement from internal auditing- A case study. Software Quality Journal, 14(1), 53-64.
Gerrit, S., De Beelde, I., & Everaert, P. (2009). Internal audit: a comfort provider to the Audit Committee. British Accounting Review, 90-106.
Harvard University. (2017, June 6). Harvard Financial Administration: Risk Management and Audit Services. Opgehaald van Risk Management & Audit Services:
https://rmas.fad.harvard.edu/faq/what-integrated-audit
Hass, S., Burnaby, P., & Abdolmohammadi, M. (2006). THe Americas literature review on internal auditing. Managerial Auditing Journal, 21(8), 835-844.
44 Instituut van Internal Auditors. (2012). Samenwerking tussen Operational- en IT-Auditor. Intituut van
Internal Auditors.
Ktata, O., & Levesque, G. (2010). Designing and implementing a measurement Program for Scrum Teams: What do agile developers really need and want? Conference on Computer Science & Software Engineering, 101-107.
Larman, C. (2005). Agile and Iterative Development: A Manager's Guide. Boston: Pearson Education Inc.
Leeuwen, S. (2016, October 6). Is Agile Hip of een Hype? Opgehaald van Management site: https://www.managementsite.nl/agile-ondernemen-noodzaak-hype
Mahadevan, D. (2017, January). ING’s agile transformation. Opgehaald van McKinsey: http://www.mckinsey.com/industries/financial-services/our-insights/ings-agile- transformation
Mahnic, V., & Zabkar, N. (2008). Using COBIT Indicators for Measuring Scrum-based Software Development. WSEAS Transactions on Computers, 1605-1617.
Martijnse, N., & Noordam, P. (2007). Project Management: Lessen uit falende en succesvolle ICT projecten. MCA, 40-48.
Maruping, L. M., & Venkatesh, V. (2009). A Control Theory Perspective on Agile Methodology Use and Changin User Requirements. Information Systems Resarch, 377-399.
McNamee, D. (1997). Risk-Based Auditing. Internal Auditor, 22-27.
Merriam-Webster. (2016). The Merriam-Webster Dictionary. Springfield: Merriam Webster Inc. Misra, s., Vinod, K., Uma, K., Kamel, F., & Mahmud, A. (2012). Agile software development practices:
evolution, principles and criticisms. International Journal of Quality & Reliability Management, 972-980.
Molenkamp, A. (2005). Internal Auditprofessie bewijst haar bestaansrecht. Finance & Control, 40-45. Murdock, H. (2016). Operational Auditing: Principles and techniques for a changing world. Boca
Raton: Auerbach Publications.
Nagy, A. L., & Cenker, W. J. (2002). An assessment of the newly defined internal audit function. Managerial Auditing Journal, 130-137.
45 Offeren, D. (1999). Schets van de samenhang van de kwalitatieve eigenschappen in Stramien. de
Accountant, 396-399.
PwC. (2006). PricewaterhouseCoopers' State of the Internal Audit Profession: Internal Audit Post Sarbanes-Oxley. New York: PricewaterhouseCoopers LLP.
Schipper, K. (2003). Principle-Based Accounting Standards. Accounting Horizons, 61-72.
Schwaber, K. (1997). Scrum development process. Business Object Design and Implementation, 117- 134.
Schwaber, K., & Sutherland, J. (2016, June 11). The Scrum Guide: The rules of the Game. Opgehaald van www.scrum.org: https://www.scrumguides.org/
Sijben, M. (2015, 6 7). Afstudeerscriptie: Veranderende IT audit aanpak bij agile software- ontwikkeling. (M. P. Slotema, Interviewer)
SOX. (2002). Sarbanes-Oxley Act of 2002. HR3763: One Hundred Seventh Congress of the United States of America.
Takeuchi, H., & Nonaka, I. (1986). New Product Development Game. Harvard Business Review, 137- 146.
The Institute of Internal Auditors. (2016, October). International Professional Practice Framework (IPPF). International Professional Practice Framework (IPPF). Lake Mary, FL, USA: The Institute of Internal Auditors.
46
Appendix A:
Voorbeeld - Minimum Viable Product
Preliminary Results report
Audit of Back office application AAM
Progress:
Finished 1 sprint out of planned 6
Based on the relative risks associated to the processes in scope and the mitigating impact of identified controls the key areas of risk were prioritised:
User Access Management Controls
The following Key risk areas are in scope but have not yet been evaluated:
Application Governance
Input, output and processing controls Change Management controls Application availability controls
Identified issues:
The evaluation of User access management controls resulted in the following:
Title: IT engineers have permanent high privileged access to Front Office applications that process data rated as secret and confidential
Norm: The User Access Minimum standards require that access to privileged operations shall be restricted and controlled based on the least privilege principle. The User access minimum standard states that “where the use of a privileged operation is required by an event, the use of the privileges shall be rescinded following the event”. In addition, the User access Minimum standard states access to IT assets is restricted based on the ‘need to know, need to have’ principle.
Identified condition:
The Accounting applications process and store data rated as confidential (C3), secret (C4), Double intervention (I4) and individual (I3). The evaluation of the user access verification process revealed the following:
- IT engineers are allowed by application authorisation design matrices (SOLL) to obtain high privileged accounts using their personal password on a permanent basis;
- The authorisation design matrices of the in scope applications (containing data rated as C4 and I4) is not complete as non-personal accounts were identified that were not included in the authorisation design matrix; and,
- No Soll-Ist verification of the authorisation design matrices has been performed for the IT Engineer business roles.
Root
cause: The root cause is derived from the fact that the in scope DevOps teams operate in a readily changing environment and the need to cooperate with many different stakeholders with different requirement
priority settings. Further, insufficient understanding of control objectives leads to implemented measures that partly meet the control objectives and result in control deficiencies.
Risk: Lack of an adequate authorisation design matrix increases the likelihood of unauthorised access and
unauthorised modification of applications data and transactions and unauthorised disclosure of secret and confidential data.
47
Appendix B:
Voorbeeld - Audit Backlog
Functional Requirements:
Risk assessment:
Regulation requirements and identification of relevant policies Financials & Non-Financials
Business Analysis IT Analysis
Key areas of risk:
Application Governance • Asset Owner;
• Segregation of Duties; • Business Impact Analysis; • Risk assessment; and • Service Level Management. Application Controls • Input Controls; • Processing Controls; • Output Controls; • Interfaces; and • Audit Trails.
Application User Access Controls • User Administration;
• User Authentication and Authorisation; and • Generic accounts.
Application Change Management • Changes are authorised; • Changes are tested;
• Segregation of environments; and • Patch and Life Cycle management. Application Availability
• Disaster Recovery planning and testing; and • Back-up and recovery.
Security Monitoring
• Security Monitoring; and • Security Scanning.
Non functional requirements:
File creation
Announcements, timescales and resource allocation Client contacts and report distribution list
48
Appendix C:
Voorbeeld - User story: Risico Analyse
Work to be performed:
1. Assess relevant financial (e.g. balance sheet, P&L, RWA, VAR limits, INCAP, balances on suspense accounts, etc.) and non-financial figures (e.g. FTEs, number of complaints, etc.) to illustrate the relevance of the department or entity in scope and the impact on the Audit Work Programme.
2. Perform an analysis of the business processes to identify inherent risks and other attention points. Determine the impact on the Audit Work Programme and include reference to the relevant Key Area of Scope
3. Perform an analysis of the IT environment (applications used for the activities in scope) to identify inherent risks and other attention points. Determine the impact on the Audit Work Programme and include reference to the relevant Key Area of Scope.
49
Appendix D:
Voorbeeld User Story: User Administration
Work to be performed:
Accounts should be created and maintained. User Administration is a control that is responsible to ensure that is done properly. Do the following to assess User administration of the application in scope:
- Determine who is responsible for the administration of User Access in the application. The responsibilities for processing access requests and creating, modifying and removing access should be an independent function.
- Verify that the user administration tasks cannot be performed unnoticed (e.g. dual control principle or security event monitoring implementation).
- Obtain a list of accounts recently added or modified. On a sample basis determine that requests were documented and authorised.
50
51
Appendix F:
Tabel kernbegrippen
Agile Scrum Begrip:
Toepassing bij Audit:
Product Het uiteindelijke oordeel en de daarbij behorende bevindingen over een object van onderzoek dat wordt opgeleverd door een interne audit afdeling. Het oordeel wordt over het algemeen in rapportage vorm gecommuniceerd.
Per sprint wordt een op leverbaar oordeel gerealiseerd in de vorm van een rapportage, echter aangezien dit niet het volledige oordeel zal betreffen totdat de laatste sprint is afgerond, zal het oordeel een beperkte mate van zekerheid betreffen of een oordeel over een beperkte scope.
Iteraties Een iteratie is een tijdbox van één tot vier weken waarin een verbetering aan werkend product wordt gerealiseerd. Sprint Bij audit zal een sprint maximaal 2 tot 3 weken duren.
Product/ Audit back log Op het product backlog of in dit geval het audit backlog staan alle requirements waaraan het oordeel in de vorm van een rapportage zal moeten voldoen. Deze requirements worden gedefinieerd door de uiteindelijke gebruiker van de audit rapportages en zullen derhalve gericht zijn op de betrouwbaarheid en relevantie van het oordeel. Zie appendix B voor een voorbeeld backlog.
User stories Van elke ‘User story’ is duidelijk wie de verantwoordelijkheid heeft, welke werkzaamheden verricht moeten worden, en hoe dit bijdraagt aan de kwaliteit van het oordeel.
Het Gross van de ‘User stories’ omvat het beoordelen van de opzet, bestaan en werking van controle maatregelen die relevante risico’s afdekken. Afhankelijk van de prioriteit van een specifieke ‘user story’ wordt deze op de sprint ‘back log’ geplaatst. Op de sprint ‘back log’ staan alle audit werkzaamheden die gedurende de desbetreffende sprint uitgevoerd en opgeleverd dienen te worden.
De prioritering van ‘User stories’ zal afhankelijk zijn van de risico inschatting en de mate van mitigeren van de relevante risico’s. Zie appendix C & D voor een voorbeeld User stories.
Definition of Done Teneinde een oordeel aan het eind van elke sprint te kunnen rapporteren en deze moet voldoen aan de standaarden voor interne audit is het van belang dat elke ‘user story’ voldoet aan minimale acceptatie criteria alvorens deze als gereed gemeld kan worden. Deze acceptatie criteria worden in agile terminologie ‘Definition of Done’ genoemd.
Elke ‘User story’ moet voldoen aan de ‘Definition of Done’ zodat de betrouwbaarheid en de relevantie van het oordeel gewaarborgd blijven. Feitelijk betekent dit dat voor elke ‘User story’ werkzaamheden uit de planning, veldwerk en rapportage fase verricht moeten worden. Zie appendix E voor een voorbeeld Definition of Done.
Product owner Dit is veelal de audit manager of de audit afdelingshoofd. Het is de taak van de product owner om de wensen en requirements van de eindgebruiker te behartigen en er voor te zorgen dat het eindoordeel voldoet aan de kwaliteitsaspecten relevantie en betrouwbaarheid. Het derhalve ook de
verantwoordelijkheid van de product owner om te bepalen welke user stories op de audit back log komen en welke user stories prioriteit krijgen en op de sprint backlog geplaatst worden. Het is aan de product owner om te beslissen of een oordeel wordt gecommuniceerd aan de eindgebruiker.
52 Scrum Master De scrum master zorgt er voor dat het scrum proces is begrepen en wordt uitgevoerd conform afgesproken spelregels De scrum master helpt eventuele
obstakels die zich voordoen gedurende de werkzaamheden te overkomen. In de audit praktijk zal deze persoon over het algemeen de Audit lead of supervisor betreffen die op de dagelijkse werkzaamheden toeziet of minder ervaren teamleden begeleidt. De scrum master is verantwoordelijk voor de kwaliteit van de uitgevoerde werkzaamheden en het oordeel dat elke sprint wordt opgeleverd. De scrum master zal uiteindelijk waarborgen dat aan de audit standaarden wordt voldaan en uiteindelijk het betrouwbaarheidsaspect van het eindoordeel in het kader van dossiervorming gewaarborgd is door User stories te toetsen aan de 'Definition of Done'.
Scrum Team Het Scrum audit team bestaat uit 3 tot 6 leden en betreft auditors waar noodzakelijk uit verschillende disciplines zoals IT, operationele en financiële auditors en waar noodzakelijk specialisten vanuit specifieke vakgebieden. Intensieve samenwerking wordt nagestreefd ten einde de werkzaamheden die op de sprint backlogs staan te realiseren. Het scrum team bepaald samen met de product owner de planning van elke sprint, zodat realistische planningen worden opgesteld. De intensieve samenwerking en de opbouw van teams vanuit verschillende audit disciplines bevordert een holistische benadering van bevindingen en draagt derhalve bij aan het uiteindelijke oordeel.
Backlog refinement meeting/ Backlog grooming meeting
In de backlog refinement meeting hoeft niet per se een meeting te zijn maar betreft wel een belangrijke activiteit die uitgevoerd dient te worden. Door middel van deze activiteit, meestal uitgevoerd per sprint, worden de requirement zoals deze op de backlog staan verfijnd in User stories. Wanneer backlog requirements zijn gegroepeerd in processen of risico gebieden kan tijdens de backlog refinement de specifieke controlemaatregelen uitgewerkt worden in User stories. De product owner kan samen met het team het werkprogramma op controle maatregel niveau het werkprogramma specificeren teneinde de focus en de juiste mate van diepgang te bepalen.
Sprint planning meeting De sprint planning meeting wordt gehouden aan het begin van elke sprint waarbij een onderhandeling plaatsvindt tussen het Audit team en de Product owner over welke User stories van de Audit Back log op de sprint Backlog worden geplaatst. Het blijft de verantwoordelijkheid van de Product Owner of Audit manager om de prioriteit te bepalen van de User stories gebaseerd op de kwaliteitsaspecten relevantie en betrouwbaarheid. Het is de
verantwoordelijkheid van het team eigenaarschap te nemen van de hoeveelheid werk die zij in een sprint gedaan kunnen krijgen.
Daily Scrum meeting Deze slechts 15 minuten durende meeting wordt dagelijks gehouden en heeft als doel de voortgang van de sprint te bewaken, obstakels te identificeren en de aanpak voor de werkdag te bepalen. De achterliggende gedachte van deze meeting is om te voorkomen dat werk verdeeld wordt tussen audit teamleden waarna onafhankelijk van elkaar de werkzaamheden worden uitgevoerd. Door middel van de Daily Scrum meeting worden audit teamleden gedwongen met elkaar te communiceren waardoor wederom de samenwerking wordt bevorderd. Obstakels zoals eventuele bevindingen worden besproken waardoor de bevinding holistisch vanuit verschillende vakgebieden wordt geëvalueerd.
Sprint Review meeting De intensieve betrokkenheid van de eindgebruiker wordt gerealiseerd door middel van de Sprint Review meeting. Tijdens deze meeting wordt het oordeel en de daarbij behorende bevindingen die voortkomen uit een sprint gedemonstreerd aan de eindgebruiker (minimaal in de vorm van de Product owner), de auditee en eventueel andere belanghebbenden. In deze meetings wordt feedback gegeven op de bevindingen en de feitelijke juistheid bepaald. De Product owner beoordeelt of de User stories die op de Sprint planning zijn geplaatst klaar zijn en bepaald of aanpassingen in het werkprogramma en risico
assessment noodzakelijk zijn teneinde de relevantie van het eindoordeel te verhogen. De feedback verkregen in deze meeting faciliteert het iteratieve proces.
Sprint retrospective Elke sprint wordt afgesloten met een Retrospective meeting. Het doel van deze meeting is om te reflecteren op het Agile Audit proces. Teamleden geven elkaar of het Team feedback waardoor actie ondernomen kan worden om gedrag en de samenwerking tussen de verschillende teamleden en audit expertises te verbeteren in toekomstige sprints.
53
Appendix G:
Gespreksverslagen
In het volgende overzicht staan de personen die ten behoeve van dit verslag zijn geïnterviewd. Naam: Organisatie/ Functie: Expertise:
Michel Sijben NOREA / Lid van Kennisgroep Agile Software ontwikkeling en Interne Audit
Geert-Jan Krol NOREA / Lid van kennisgroep Agile Software ontwikkeling en Interne Audit
Vincent Hoefakker ING/ Audit department Head Quality assurance en audit methodologie.
Steven Clausing BINCK Bank / COO Auditing, potentiele gebruiker, relevantie voor auditee
Jan Haverkamp ING/ Audit department Head Auditing, ervaringsdeskundige met Agile en potentiele gebruiker en relevantie voor gebruiker
Abel van Willingen Achmea/ Senior IT auditor Auditing, ervaringsdeskundige met Agile en potentiele gebruiker en relevantie voor gebruiker
Jeroen Bekkers Rabobank/ IT Audit Manager Auditing, ervaringsdeskundige met Agile en potentiele gebruiker en relevantie voor gebruiker
De interviews zijn genotuleerd en de notulen zijn bevestigd door de geïnterviewden. Vanwege het feit dat inzicht is gegeven in het functioneren van interne audit afdelingen van beursgenoteerde bedrijven is besloten de notulen niet op te nemen in het verslag. De notulen zijn wel beschikbaar bij de schrijver van dit verslag.