Showing posts with label documentation. Show all posts
Showing posts with label documentation. Show all posts

Auditing for the Masses

In summary terms, risk management identifies, prioritizes, and safeguards critical assets, while policies, procedures, and standards address employee conduct. Auditing is the process of assessing whether employees and business operations are in compliance with the organization's policies and procedures as well as applicable laws and regulations. Auditing is the investigation and measurement of employee behavior and business operations based on collected evidence. Counted together, risk management, policies and procedures, and auditing form the first three integrated steps in proactively addressing critical incident management.

Auditing is the compliance extension of your risk management program where operations, policies, and procedures are examined to determine whether operations are lawful, effective, efficient, and profitable. Auditing will determine that the organization's critical assets are accounted for, prioritized with adequate safeguards, and whether recovery and restoration procedures are implemented and tested. Fundamentally, auditing is also a comparison and analytical process comprised of collecting and evaluating evidence regarding management assertions and the actual state of the organization's operations. In fact, the most-critical part of auditing is the degree of separation between an organization's assertions and established system-addressed risk criteria. Any differences between assertions and the actual-state falls into a category called the "gap."

Information technology auditing is a carefully planned and executed business process involving the collection and evaluation of evidence to ascertain if a computer system safeguards critical assets and facilitates organizational goals being achieved.

Auditor Responsibilities
In the sense of their function, auditors must not have any direct responsibility or authority over any of the activities that they examine or could examine in the future. Operational assessments and employee performance appraisals do not, in any way, relieve employees of their professional responsibilities. Auditors must be authorized to have full and unrestricted access to relevant equipment and information including computer files, documents, records, property and employees. They must have a high degree of freedom in all audit-applicable business areas with the exception of specific restrictions imposed by law.

Internal Controls
Managing critical assets, their safeguards, controlling potential frauds and improving effectiveness and efficiency can best be achieved if senior managers establish a structure of internal controls. There really is not a great deal of universal details in this area as all organizations are different in their mission and function. Let's define internal controls here in the context of formal systems that prevent, detect, and correct policy violations, unlawful and abusive events. These are the three most important levels of general controls: prevention, detection, and correction.

General Controls
General controls are those internal controls having wide application to most areas of business operations. For the most part, they include but are not limited to specific system applications:

  • Planning and organization controls

  • Physical and logical access controls

  • Human resources

  • Risk management

  • Communications controls

  • System development controls


  • Specific Controls
    In broad terms these are controls with application to specific applications:

  • Access controls

  • Data input controls (these include all system data inputs)

  • Processing controls

  • Output controls


  • The overarching governing structure for specific and general controls is that of CIA, confidentiality, integrity, and availability. In current auditing views, there are many components where internal controls apply for example, separation of duties and least privilege, clear lines of authority and responsibility, adequate documentation, access control, management supervision, individual accountability, performance checks, and audit trails to name a few.

    Separation of Duties and Least Privilege
    Separation of duties basically means that separate employees should be responsible for initiating transactions, processing transactions, recording those transactions, and maintaining custody of critical assets. Least privilege means that employees have the knowledge and authority to perform their jobs and nothing more. For example, in a small organization an accounts payable clerk has the responsibility of preparing billing payments. She reviews the billing for its correctness and prepares wire transfer documents. By observing the concepts of separation of duties and least privilege, she does not have the authority or the ability to release funds. So, she prepares a voucher with the attached billing documentation and submits these materials to the finance vice-president who authorizes the transfer of funds. In the event the payment amounts are over $10,000, the organization's policies and procedures mandate that two vice-presidents approve the electronic wire transfer. Once the payment is approved, the transaction information flows to another employee that is responsible for posting the transaction to the organization's financial records.

    Authority and Responsibility
    Clear and well-defined lines of authority and responsibility are essential in controlling systems. In today's business environment, the distinctions between authority and responsibility may not be clear. It is frequently difficult as many resources are shared among many users. For example, database use is common among many users in a business organization. When several authorized users have simultaneous access and, through some unknown means, the data becomes corrupted, it is not always easy to fix responsibility.

    Documentation
    Documents and records are essential in providing an audit trail of activities within any system. Electronic and paper-based documents are used to support the initiation, execution, payment, and recording of transactions. Documentation is intended to provide an accurate record of events and acts. Documents should provide a tangible record in which events can be reconstructed from their content. In a well-designed system, audit trails document the actions and events occurring during business operations as well as those documents required to administratively run the business.

    Performance Checks and Accountability
    Checks of performance and accountability are done by auditors because employees are likely to forget policies and procedures, make genuine mistakes, become careless and negligent, or intentionally fail to follow procedures. Individual employee accountability is tied to performance and competence as well as continuing responsibility.

    Systems Development Lifecycle (SDLC)

    The SDLC is a mechanism assuring that systems meet established requirements and further the organization's business strategic goals. It provides a structured approach to managing projects, beginning with the justification for initiating development or maintenance efforts and concluding with system disposal.

    Most organizations spend millions of dollars annually in the acquisition, design, development, implementation, and maintenance of information systems. The need for secure and reliable system solutions is easily recognized by the dependence on computer systems needed to provide products and administer daily activities.

    SDLC methodology establishes policies, procedures, and guidelines managing project development, planning, requirements analysis, design, development, integration and test, implementation, and operations, maintenance, and disposition of information systems. The SDLC is not the do-all, be-all, end-all methodology. There are many permutations of it, but those concepts will not be addressed in this section. However, SDLC is one development method that has a proven track record and should be integrated with already-existing organization policies and procedures.

    SDLC Benefits
    Reduced risk of project failure

    Consideration of user requirements throughout the system's lifetime

    Early identification of technical, performance, and management issues

    Description and disclosure of all costs guiding business decisions

    Realistic user expectations of what the system will deliver

    Identification of systems and processes that are no longer cost effective

    Measurements of project progress to enable necessary corrections

    Supports effective resource and budget planning and accountability

    Identifies current and future business requirements


    SDLC Supports the Use of an Integrated Product Team
    The SDLC project team can provide for the project's success. It should be an interdisciplinary group composed of a senior management project sponsor, a project manager, and team members responsible for planning, implementation, and delivery. Team members should comprise senior employees representing business units such as user groups, human resources, program/functional management, quality assurance, security, legal, telecommunications, data administration, database administration, logistics, financial, systems engineering, test and evaluation, contracts management, audit, physical facilities, and configuration management. Working together in a proactive, open-communication, team-oriented environment can build a successful project by providing decision makers with the necessary experience and information to make the right decisions at the right time.

    The SDLC has nine phases or steps that will be briefly described:

    SDLC System Concept Development Phase. This project concept initiates the development lifecycle. It begins when a business need, based on operational requirements, is identified. Once the operational requirement is expressed, the approaches for meeting it are reviewed for necessity, feasibility, reasonableness, and appropriateness. The need may involve development of a new product or the modification of an existing system. Senior managers are usually the responsible officials for approvals and funding before the planning phase can begin.

    Planning Phase. A program plan is developed documenting the approach to be used, including the formulation of methods, tools, resources, schedules, user input, funding, audit, and risk management.

    Requirements Analysis Phase. User requirements are formally defined along with the requirements of system performance, data, risk management, and maintenance. All requirements are detailed to such a level that it is sufficient for designers to proceed.

    Design Phase. The external characteristics of the system are designed during this phase. Operating environments are established, major sub-systems with their required inputs and outputs are defined. At this time, processes are allocated to resources. User input is documented, reviewed, and modified, and final approval is made. Internal characteristics of the system are described, specified, and designed. Required logic specifications are prepared for software modules.

    Development Phase. Detailed specifications produced during the design phase are translated into hardware, software, and communications links. Software is integrated, tested, modified if necessary, and retested.

    Integration and Test Phase. System integration, risk management, and user acceptance are conducted during this phase. Users, audit, and quality assurance units validate the functional requirements, as defined in the functional requirements documentation. It is important that these functional requirements are satisfied by the developed system.

    Implementation Phase. The systems are installed and made operational initially in a test environment. After successful testing, the system is made operational in a production environment. This phase continues until the system is operating in production in conformity with user requirements and design parameters. Its security is certified. In this phase, it is accepted or rejected by users.

    Operations and Maintenance Phase. By now the system is operating and is monitored for continued performance, satisfying user requirements. If needed, system modifications proceed through a requirements and necessity phase; they are scheduled, designed, tested, and implemented. If more than relatively simple modifications or changes are identified, the system will reenter the planning phase.

    Disposition Phase. Disposition activities ensure the orderly review, modification, and termination of the system. Emphasis is granted to the preservation of data processed by the system in order for data to be migrated to another system or stored in compliance with records management policies, laws, or regulations for future accessing and processing.


    Management Controls
    The SDLC requires the following comprehensive management controls:

    Structured approach to systems development, operation, and disposal

    A senior management sponsor, preferably someone with a cheerleader's enthusiasm

    Project management limited to a single, accountable project manager

    Comprehensive project planning required for each system project

    Projects proceed when sufficient resource availability is assured

    Organized and accessible documentation of all steps, decisions, deliberations, agreements, requirements, plans, proposals, schedules, risk management, security measures, quality controls, funding, auditing, and meetings


    Documentation
    The SDLC specifies that documentation shall be generated during each phase. The principal categories of documentation are divided into two types:

    1. Process documentation details actions taken for developing, implementing, testing, and maintaining the system. Process documentation includes but is not necessarily limited to plans, notes, meeting minutes, deliberations, funding, schedules, charts, funding expenditures, auditing documents, quality control decisions, reports, and time and attendance reports.

    2. Product documentation includes matters that detail the system itself, what it is, how it is operated, how it is maintained, and future disposal. Examples include but are not limited to technical manuals, user manuals, operations manuals, maintenance manuals, systems requirements documentation, and design documentation.


    It should be noted that some documentation will remain relatively static throughout the system lifecycle and some will be continuously changed. Some documents are revised documenting the results of analyses performed during operations. Each document should be collected, stored securely, and protected for future reference. It is important that regulatory and legal issues are addressed before any documentation is destroyed. Undocumented or inadequate documentation of decisions and events can cause significant confusion or wasted efforts and can intensify the effect of team member turnover. Activities should not be considered complete, nor decisions made, until there is sufficient documentation of the activity or decision. In the case of some very large projects, there cannot be advancement to the next SDLC phase without the required audits, management reviews, and appropriate approvals.

    Popular Posts