Perhaps the biggest difference between the old and the new
standard is the structure. ISO IEC 27001 2005 had five main sections
(4 to 8) and ISO IEC 27001 2013 has seven (4 to 10). This is because the
new 2013 edition uses the new Annex SL template. According to ISO,
all future management system standards (MSSs) will use this new
layout and share the same basic requirements. Because of this,
all new MSSs will have the same basic look and feel.

A common structure is possible because concepts such as policy,
procedure, planning, process, monitoring, controls, audits, reviews,
nonconformities, corrective actions, measurements, and certification
are common to all management system standards. While this will make
it easier for organizations to implement multiple standards because they
will all share the same basic requirements, it may cause some disruption
in the short run as organizations get used to the new structure.

In general, the new standard is more focused than the old. And even
though it has more sections (seven vs five), it is roughly 25 % shorter,
(excluding annexes). This should make it easier to work with.

For the most part, both the old and the new standard cover
essentially the same topics. However, there are some important
differences between the old and the new.

The new ISO IEC 27001 standard no longer emphasizes the process
approach nor does it expect you to understand what PDCA means.
It recognizes that you really don't have to understand these two
ideas to use the standard. While the new standard still talks about
processes, the process approach is no longer front and center.
While the old standard had an entire subsection on the process
approach, the new standard simply ignores it. In addition, the old
PDCA graphic has been eliminated, thank goodness. It was both
misleading and incomprehensible (quite an achievement).

Preventive action is also gone. As people began to use the old
ISO IEC 27001 standard, they started to realize that once you start
doing risk assessments to choose risk treatment options, there is no
real need to have a separate preventive action clause. This is because
risk management is already concerned about preventing potential
problems. That’s the whole point of risk management. Once you start
using risk management techniques, preventive action is redundant.

The new ISO IEC 27001 2013 standard has also eliminated the
long established distinction between documents and records.
Now they are referred to as “documented information”. Why ISO
decided to abandon two common sense concepts with one that is
not only awkward but needlessly esoteric, is not entirely clear.

Another new and unusual concept is what ISO IEC 27001 2013
calls context. The new standard now expects you to understand
your organization's context before you establish its ISMS. When the
new standard asks you to understand your organization's context it
means that you should understand the needs and expectations of its
stakeholders, its approach to governance, its culture, its capabilities,
its legal obligations, and its political, economic, technological, and
regulatory environment. And once you understand all of this,
you're expected to use these insights to help you define the
scope of your ISMS and the challenges it must deal with.

Since a note to clause 4.1 asks you to refer to the ISO 31000 2009 risk
management standard to figure out what it means to establish context,
this new standard is now central to ISO IEC 27001. In fact, it’s probably
fair to say that ISO 31000 now provides at least a partial conceptual
foundation for ISO IEC 27001. This is true not only because you’re
expected to establish your context, but also because ISO IEC 27001
now wants you to use ISO 31000’s concept of risk and to be guided
by its approach to risk assessment and risk treatment (clause 6.1.3).

Because of this, ISO 31000 risk management concepts and methods
now permeate the new ISO IEC 27001 2013 standard and will certainly
influence how it is applied. While this will help ensure that organizations
develop information security management systems that address their
own unique needs and requirements, doing all of this could be quite
a challenge for some organizations.

However, not all aspects of the new standard are more challenging.
Annex A is now probably easier to use. While the new standard still
lists control objectives and controls, it’s now going to be a bit easier
to use Annex A because you can now ignore control objectives
if you want to do so. While the old standard declared that the
"control objectives and controls from Annex A shall be selected and
implemented" (clause 4.2.1), the new standard simply asks you to
"produce a Statement of Applicability that contains the necessary
controls" (clause 6.1.3). There’s no mention of control objectives.

So, according to the new standard, you don't need to include
objectives in your Statement of Applicability, although you do,
of course, need to select controls. According to clause 6.1.3,
“Control objectives are implicitly included in the controls chosen”.
Presumably this is why you’re allowed to ignore control objectives.